4 ms·
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
by greggman3 7y ago
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
https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo#formatting https://github.com/flutter/flutter/wiki/Style-guide-for-Flut...
- biddlesby 7y agoIt'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.
- greggman3 7y agoThe 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.
- faeyanpiraat 7y agoWell you've just documented examples of your personal style, which can be made into custom rules for the formatter. Maybe using some natural language processing, machine learning, and crowdsourcing, a formatter could understand intent sooner or later?
- michalhosna 7y ago> ... which can be made into custom rules for the formatter. Yep, well, dartfmt is almost non-configurable, without custom rules. Because consistency over everything. One of the greatest frustration trying to setup flutter in production for me. And no other formatter for dart I know of. The configuration will change, all formatters I know added configuration eventually, but man!.
- SifJar 7y agoFrom the Flutter link: > 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
- anthonybullard 7y agoThey 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. Source: former team member
- rat87 7y ago> Or maybe you require brackets. Your style should require brackets, and probably not be a single line
- Latty 7y agoLanguage-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.
- vlovich123 7y agoI 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. [1] https://github.com/search?q=CheckPatchFormatted+repo%3Achromium%2Fchromium+filename%3APRESUBMIT.py&type=Code https://github.com/search?q=CheckPatchFormatted+repo%3Achrom...
- KwanEsq 7y agoAs far as I know, Firefox/Gecko uses clang-format for C++, rustfmt for Rust, and most recently Prettier for JavaScript.
- roryokane 7y agoI 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 https://prettier.io/docs/en/ignore.html) are not this powerful – they only support ignoring the next line of code.