[josephg]

I can’t speak for the author, but personally I hate tools like go fmt, es-prettify and cargo fmt. I’d never use this stuff by choice because they delete the work I do to make my code easier for me to read. For example, I use extra blank lines to separate different parts of a function, or separate groups of functions visually. These sort of tools like to delete vertical white space, which hurts readability. In javascript I’ve seen plenty of very readable ternary operators (possible with the correct layout) replaced with unreadable junk by the prettifier.

It’s soulless to make all code look like bland corporate cardboard. It appeals to our OCD perfectionist tendencies but in my experience provides very little real value. Software is like writing. It can’t help but express how the author thinks about their code. These tools try to iron that personality out - and for what reason? Who cares in javascript if some files use semicolons and some don’t? Who cares if my where clause is on the same line or the next? The compiler doesn’t care, and neither do I.

(I will grant that all files in a project should have consistent white space, but you don’t need cargo fmt for that.)

[rav]

> Software is like writing. It can’t help but express how the author thinks about their code. These tools try to iron that personality out - and for what reason?

A single-author novel can have personality. A 100-author 30-volume encyclopedia, less so. Whenever I set up a new single-author codebase, I set up as little automatic code formatting as I please. For collaborating with other developers, I will enforce as much as possible as early as possible.

[rhooke]

I enforce formatters wherever possible after working on codebases with 20+ years of people imposing their own unique opinion on where spaces and braces should go. Worse, arguing about what the spacing should be, and making noisy diffs because people change previous peoples styling.

The formatter has no opinion. It follows rules. It doesn't work perfectly everywhere. It works enough. I would argue caring about exact bespoke spacing of all code is the perfectionism you mention.

[childintime]

There is no reason why each of us can't have the formatted according to one's taste (=what works best), instead of this "communism". It's just a matter of IDE support that is lacking.

The IDE should apply user formatting preferences upon reading in the file, and apply the std formatting while writing it (with the aim of having diffs work well). That would make good use of auto-formatters.

[ketralnis]

Okay, but the IDE support is lacking so that workaround isn't available. If you want that functionality instead you'll have to (1) add it to your IDE (2) force your team to use your favourite IDE instead of their favourite IDE. Insisting on some alternate reality where you have different tools than you actually have isn't helpful

[krageon]

> communism

It's in precisely zero ways like communism and that really doesn't help the clarity of the rest of your post.

[Thaxll]

This is bad idea, so you want your code to not looks like what's in the repo?

[ketralnis]

I think it's bad without the rest of the supporting toolchain but it's not axiomatically bad. There are languages with structured editors (e.g. https://hazel.org/), people can use different tabstop settings and even just different editor colours and wrapping settings and I think we can agree that doesn't doesn't hurt anything. Enforcing an automatic formatter is more or less identical to this anyway: you can write your code using whatever style you want but what ends up in the repo is equivalent to the compiler but not identical to what you wrote. You can imagine running your own local formatter on the code before you edit it and running the global formatter afterwards and an observer being unable to tell that that's happened.

[postalrat]

Who said that?

[krageon]

> for what reason?

Perhaps you do not remember reading through 10k lines of PHP source that has been formatted by someone who has entirely different ideas about what good formatting is than almost everyone else on earth (or perhaps you never have!), but if you did remember the advantage of a single formatting standard that is ubiquitous would be very clear.

[stefs]

while i agree with you on some parts (ternary operators for example), i love the autoformatters for two reasons:

1. it makes it just plain easier to read others code. it's hard enough to have to grasp the logic behind everything, if they have wildly different formatting on top of that it gets substantially worse (incidentally, this was given as one of the reasons why go was such a success in the open source world).

2. i've been able to get a couple of archaic linter rules dropped, i.e. the brackets around single statement conditionals.

    // for this reason brackets were mandatory
    if (a == b)
        doSomething();
        doSomethingElse();

now with an auto formatters indentation fixes, this mistake becomes instantly obvious and thus a non-issue.

[noobermin]

Disappointed by the downvotes here. While formatters help in most instances, sometimes you should break convention for the sake of emphasis or readability. Anyone here can come up with a good example for themselves. Consistency is the hobgoblin of little minds. Patterns and rules help but no rule should be absolute, judging people's quality of code is like judging people for their dress or their vocabulary. While they are important they are certainly not sufficient for a judge of one's character.

[zerr]

Exactly, that's why e.g. C++ projects have some personality feel while Java codebases feel like all the same corporate bland. Go is meant to be Java replacement in corps, so...

[zesterer]

rustfmt does not delete vertical whitespace in that way.