AFAIK no formatting can understand intent. Example. I want my canvas.drawImage calls that take 9 arguments to be formatted with arguments 2-5 on one line, and 6-9 on another line because 2-5 are sourceX, sourceY, sourceWidth, sourceHeight, and 6-9 are destX, destY, destWidth, destHeight.
That's just one example of 100s where an auto formatter can not figure out intent.
Another example, I often align numbers and width and height
// convert from screen coords to clip space
clipX = mouseX / screenWidth * 2 - 1
clipY = mouseY / screenHeight * -2 + 1
Another example would be how to format an if block. Depending on your style guide
if (cond) single-statement
might be ok. Or maybe you want them on different lines. Or maybe you require brackets. Or maybe you don't. But there will almost ways be some place in the code where an exception to your style guide makes the code more readable. Auto formatters don't understand those exceptions.
This is why AFAIK many major projects do NOT use an auto-formatter. Firefox, Safari, Chrome for example. Because there are places where an auto-formatter will make the code far less readable. They'll give the advice that you are free to run an auto-formatter on your own changes but adding an automated one is a no-go. Even the Flutter team does not use an auto-formatter
Language-wise, the existence of "sourceX, sourceY, sourceWidth, sourceHeight" speaks to a lack of tuples or simple records more than anything.
Obviously a formatter can't change the language, but just want to point out that the issue there is really that the arguments are linked logically but not in the code.
I think a language designed around using an auto-formatter will work better in that scenario. See, for example, Elm—where the use of auto-formatting is essentially universal.
It's a trade off. We've started using a code formatter recently: the overwhelming majority of the code in our team is more readable because it's so standardised. There are a few sub-optimal lines here and there but I wouldn't trade that for going back to the wild old days.
The projects I mentioned above all have style guides. There's no "wild old days". They just don't use a auto formatter because they know there are cases where the auto formatter makes the code less readable and that there are exceptions to every style guide. It's called a style "guide" not a style "law" because it offers guidance which can be ignored when appropriate.
> We do not yet use dartfmt. Flutter code tends to use patterns that the standard Dart formatter does not handle well. We are working with Dart team to make dartfmt aware of these patterns.
So it looks like they want to use an auto-formatter
They definitely do, and most people on the team use dartfmt on at least their own code, usually through the VSCode extension. But it can get ugly in Flutter with deeply better widget trees.
I don't know about Firefox & Safari, but I think you're missing an important caveat here for Chrome:
> In directories where most contributors have already adopted clang-format, and code is already consistent with what clang-format would produce, some teams intend to experiment with standardizing on clang-format. When these local standards apply, it will be enforced by a PRESUBMIT.py check.
From the looks of it it's a lot of the tree [1].
Where manual formatting gives you some freedom in meeting the style guide, it also brings along with it errors (style guides are massive and it's not possible to remember everything) & sometimes you just make a typo. This also means that your reviewers are spending time validating against the style guide which is not only the most wasteful use of their time, it's still an imperfect process because reviewers are just like the author - they don't have the entire style guide in their head at all times and they may miss violations.
I think the solution to this would be using an auto-formatter that supports “leave this formatting alone” directives and adding them to your code where needed:
// convert from screen coords to clip space
// formatting-preserve-start
clipX = mouseX / screenWidth * 2 - 1
clipY = mouseY / screenHeight * -2 + 1
// formatting-preserve-end
That way you get the benefit of easy, convenient consistent formatting in the rest of your file at the expense of a few extra comments here and there.
Sadly, ignore comments of the Prettier formatter (https://prettier.io/docs/en/ignore.html) are not this powerful – they only support ignoring the next line of code.
That's just one example of 100s where an auto formatter can not figure out intent.
Another example, I often align numbers and width and height
Another example would be how to format an if block. Depending on your style guide might be ok. Or maybe you want them on different lines. Or maybe you require brackets. Or maybe you don't. But there will almost ways be some place in the code where an exception to your style guide makes the code more readable. Auto formatters don't understand those exceptions.This is why AFAIK many major projects do NOT use an auto-formatter. Firefox, Safari, Chrome for example. Because there are places where an auto-formatter will make the code far less readable. They'll give the advice that you are free to run an auto-formatter on your own changes but adding an automated one is a no-go. Even the Flutter team does not use an auto-formatter
https://github.com/flutter/flutter/wiki/Style-guide-for-Flut...