These days it’s very common to write whatever code you want, and a formatter automatically rewrites it to conform to the projects rules during precommit.
Which is great because it allows you to focus on intent instead of format, and completely avoids any team disagreements or change rejections for trivial bullshit.
And then somebody changes the auto-formatter settings and all of a sudden every single file changed and committe appears as having most lines changes and you loose the ability find the real code changes between a version before that and the current version.
Guess how I found this out …
Standardizing code format via that path only works well if you start it really early in the project and never change it after that.
(Also, it doesn’t solve the problem of different software design styles)
I hear you, but these are solve-able human problems, not code problems:
Manager: Jose revert your commit, thanks.
Jose: okay, it’s been reverted, I won’t do that again, thanks for explaining to me why exactly what I did was the wrong thing to do.
I’ve had this exact conversation about this topic at least a half dozen times over the last decade.
When it comes to legacy code, almost all auto formatting tools I’ve used allow you to ignore whole directories and files, which can be very handy for legacy areas of the codebase not yet ready for this transition.
As for scenarios where large rewrites are necessary, it’s best to separate from any actual work, so the blast radius is focused, and that commit can be marked properly using .git-blame-ignore-revs which completes fixes the history issues that are common amongst those who don’t know what they are doing.
Definitely a painful process it can be, but it’s better to fight this battle than it is to try and get 1,000 humans to agree on something as vague as “style”
Ah yes, some random intern suddenly has ‘credit’ for almost all the codebase because they ran a linter with different settings than previous linter settings…
My favourite part is when your style or the auto formatter changes over time and you have to decide between:
running the auto formatter on 200,000 12 year old code files
doing them one by one
formatting them when you have to change that file
or ignoring all the warnings forever (it’s this one, this is what you do)
Plus it doesn’t fix the problem of auto formatters writing ugly code. You can’t easily tell the auto formatter that early returns can be bracketless for brevity, but nothing else can be. Unless you add a comment like \\ ignore-rule-2753674 which makes me want to throw up
These days it’s very common to write whatever code you want, and a formatter automatically rewrites it to conform to the projects rules during precommit.
Which is great because it allows you to focus on intent instead of format, and completely avoids any team disagreements or change rejections for trivial bullshit.
And then somebody changes the auto-formatter settings and all of a sudden every single file changed and committe appears as having most lines changes and you loose the ability find the real code changes between a version before that and the current version.
Guess how I found this out …
Standardizing code format via that path only works well if you start it really early in the project and never change it after that.
(Also, it doesn’t solve the problem of different software design styles)
I hear you, but these are solve-able human problems, not code problems:
Manager: Jose revert your commit, thanks. Jose: okay, it’s been reverted, I won’t do that again, thanks for explaining to me why exactly what I did was the wrong thing to do.
I’ve had this exact conversation about this topic at least a half dozen times over the last decade.
When it comes to legacy code, almost all auto formatting tools I’ve used allow you to ignore whole directories and files, which can be very handy for legacy areas of the codebase not yet ready for this transition.
As for scenarios where large rewrites are necessary, it’s best to separate from any actual work, so the blast radius is focused, and that commit can be marked properly using .git-blame-ignore-revs which completes fixes the history issues that are common amongst those who don’t know what they are doing.
Definitely a painful process it can be, but it’s better to fight this battle than it is to try and get 1,000 humans to agree on something as vague as “style”
Ah yes, some random intern suddenly has ‘credit’ for almost all the codebase because they ran a linter with different settings than previous linter settings…
My favourite part is when your style or the auto formatter changes over time and you have to decide between:
Plus it doesn’t fix the problem of auto formatters writing ugly code. You can’t easily tell the auto formatter that early returns can be bracketless for brevity, but nothing else can be. Unless you add a comment like
\\ ignore-rule-2753674which makes me want to throw up