Hacker News Reader

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.

From 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

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.

Source: former team member

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.

[1] https://github.com/search?q=CheckPatchFormatted+repo%3Achrom...

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.

Well 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?

> ... 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!.

As far as I know, Firefox/Gecko uses clang-format for C++, rustfmt for Rust, and most recently Prettier for JavaScript.

> Or maybe you require brackets.

Your style should require brackets, and probably not be a single line