[josephg]

I hate formatters like this with a passion. I realised when I tried it that there’s hundreds of tiny editorial choices I make throughout my source files. For example, I use different numbers of new lines between functions in a file to indicate similarity or to group functions together. Sometimes I’ll put a simple function on one line - like lerp or vecadd and then make a block of similar functions in my code. Stuff like that.

By removing the maker’s marks, these tools make my code less readable. While, in my opinion, adding practically no value. I’m more than happy for every line of code to have consistent indentation (of course, but it did already). I also don't have a problem with silly but arbitrary formatting choices - like sorting my import lines. But these tools seem to drive so far for consistency that it costs readability.

That’s a nope for me. No debate.

[stavros]

These tools, like any tool of the type, bring your code to the 90th percentile. This is good for nine out of ten people, because it improves their code. It's also good for the tenth person, when he has to read the code of the other nine.

If you're the tenth person, and you work alone, or with other fastidious people, you won't like the formatter. That's fine, you don't need to use it.

[autarch]

That's fine for your solo projects. It's definitely not okay at work.

[josephg]

Why not? Whats the ROI of making the number of lines that separate functions the same across our entire codebase? That sounds completely pointless.

[autarch]

It's easier to read and refactor code when it's all formatted the same way. Otherwise diffs end up with tons of extraneous noise. Plus it adds needless decisions. If I move a function in a file with Person A's style to a file with Person B's style, do I reformat it?

What about when someone leaves the company? Is it free game to reformat everything they wrote?

Why do you need to put your mark on code at work? It's not _your_ code. It belongs to the employer. The best work is work that is useful and not an irritant long after you're gone.

[josephg]

> It's easier to read and refactor code when it's all formatted the same way.

Sometimes it matters: indentation, naming_style and bracing should match throughout a codebase.

Sometimes it makes no difference: I really don't care about the order of your import statements. It simply doesn't need to be consistent throughout a program. It doesn't matter.

And sometimes making code "all formatted the same way" makes it all worse. I think thats true for spacing between functions. Functions simply shouldn't have the same spacing between them. Nor should lines of code within a function. Whitespace is a wonderful tool for telling the reader how lines of code group together. Gofmt erases all of that to make sure "code is formatted in the same way" - but in doing so, readability is actively decreased.

> If I move a function in a file with Person A's style to a file with Person B's style, do I reformat it?

Thats up to you! Why does everything have to have a right and a wrong answer? Obsessing over this stuff is a pointless waste of time. I guess thats the point of gofmt & friends - that you don't need to think about it. But, you can also not think about it by just not thinking about it, and letting your codebase be a bit inconsistent. Its not a crime. There are no consistency police. You won't go to jail.

> Why do you need to put your mark on code at work? It's not _your_ code.

You have an identifiable style whether you like it or not. Its evident in how you name your functions and variables. In how you write your comments, and where you put them. How you order functions, and where and when you split code between files, classes and modules.

Your style is inescapably everywhere in your work. And it will always have been written by you, long after you're gone.

Are you ashamed of how you write code? Why go out of your way to write and run tools that delete your mark on your work? It doesn't make the code better. Your team will not be more productive as a result. And it doesn't improve quarterly profits.

Like it or not, we're "creatives": That is, we're people who create. The software we write is distinctly our own. Having a little pride in our work is a very healthy thing.

[JyB]

That’s for teams. No one care about an individual opinion.