style(change detection): some cleanup #834
Conversation
| @@ -805,11 +807,15 @@ class _EvalWatchRecord implements WatchRecord<_Handler>, Record<_Handler> { | |||
| break; | |||
| case _MODE_FIELD_CLOSURE_: | |||
| var closure = fn(_object); | |||
| value = closure == null ? null : Function.apply(closure, args, namedArgs); | |||
| value = closure == null ? | |||
There was a problem hiding this comment.
we use 100 columns, no need to wrap these, will revert on merge
There was a problem hiding this comment.
Up to now I have always use 80 cls because:
- It is a widely used convention,
- It is also used in the Dart core code,
- It allows seeing two files side by side.
I think we should consider making 80 the norm ?
There was a problem hiding this comment.
As I had mentioned to Victor before: I think that we should opt to use the Dart formatter. IMHO, manual code formatting is mostly a waste of time. It is even more wasteful to have to go throw a push-review-edit-push cycled because of formatting issues. Use of an auto formatter would allow our time dedicated to Angular to be more optimally used. My 2 cents.
In previous projects I have used Eclipse's reformat & clean features. This is great when, like Angular, you have code being submitted from a diverse community.
|
@chalin there's a PR/issue about hop, would you mind adding a note there to have a "verify coding convetion" rule ? I don't think auto-formatting is right as we've already discussed, but auto-checking is great |
|
Done (#766). Btw, just to be clear, by "auto formatting" I mean having a tool (or command in the Dart Editor) that I can run and have the source (re-)formatted automatically. I don't mean auto formatting on checkin (which is what I may have mentioned to you before). |
|
There is a dartfmt command included in Dart (it has an option for max line length - default 80) |
|
@zoechi 👍 |
No description provided.