Bob Nystrom
Bob Nystrom
Sam is right that the example doesn't fit the wording of the guideline. But I do think the example does a good job of showing bad code. It has *parameters*...
Hmm, this one is surprising. I would expect it to keep your original formatting.
This one is a little tricky. The formatter has special rules to handle functions in argument lists and make them more block-like, for cases like: ```dart method(thing: () { ......
The [forthcoming](https://github.com/dart-lang/dart_style/issues/1403) [tall style](https://github.com/dart-lang/dart_style/issues/1253) does a better job here and produces output the same as the original input code. :)
> Yes this is exactly what I said above, I believe it already supports opting out a file and/or region. Yes, the syntax looks like: ```dart // dart format off...
> \cc @munificent What are your thoughts on including something along these lines or do you think this documentation belongs elsewhere? I'm always somewhat hesitant to add more to "Effective...
Yeah, I think so.
Completion appears to be working. Added tests: https://dart-review.googlesource.com/c/sdk/+/466283
> We don't have experimental flags easily when we format. We convert experiments into `FeatureSet`, and this is what `parseString()` wants. So, I propose that `DartFormatter` accepts `FeatureSet` instead. I'm...
I took a little look at this today. Adding support for formatting a given `ParsedUnitResult` is pretty easy. However, I'm not sure how to test it. As far as I...