This is exactly why I roll my eyes when devs passionately argue in favor of "consistent code style" and spend hours of their lives manually linting their code. What's the point? It will be gone next year.
Did you tell the developers of 10 years ago that? I deal with their surviving shit daily, in mission-critical software, even. Gone in a year? Hah! I wish!
Not just naming conventions, or assignments in if-clauses, but files there the first indentation level is three spaces, and the rest are all four...
P.S.: And because it's that old, the change-history of a given line can be very important, so it's too late to mass-reformat everything. So you either make the file uglier by mixing "standards", or you have to hand-tweak all your changes to match.
Automated formatting like gofmt is great, and I'm a huge proponent of it. But code is so temporary that it makes no sense to spend man-hours making it look pretty.
One-off script sure, but for core product code I disagree. It's temporary in the grand scheme of things yes, but how many times will it be read before it is gone? Taking a couple extra minutes to clean things up and standardizing style pays dividends in readability, and traceability via git-blame, etc. Same goes for extended commit messages that explain the approach taken.
It's not a question of sinking tons of hours into this stuff, if you're using good tools it just becomes the way you work. Could you gain 5% efficiency by just blasting out the ugliest code you can? Yes maybe, but if it's actively developed code you could easily cost future developers much more.
Having a company wide git hook for clang-format-diff [1] really solves a lot of problems. No unrelated linting changes (unless people don't know how to use their editor, but that gets caught in code review and people learn) and consistency is kept with very little man-hours spent. Proper tooling applied pragmatically is nice.
The SMBC comic mocks the people for not being self-aware enough to realize that they are causing their own problem by being apathetic.
> "I'm not good at this because I don't try, so I won't try"
> "Girls don't like me because I have bad hygiene, so why should I bother with hygiene?"
etc.
This would only apply to what I wrote if my code was disappearing because it's not formatted to pass a linter. You and I both know that this isn't the reason code gets deleted. It gets deleted because it gets refactored, or the feature/product it's implementing gets killed.
Furthermore, code quality is not the same thing as code style.
> code quality is not the same thing as code style.
I did misparaphrase you. My apologies for that. Fixed.
But as for the other argument, I think the comic's examples and your case represent feedback loops in which two factors are both cause and consequence of each other.
I believe you that you started not caring about code style after you noticed your code tends not to last. Similarly, life was short already before bacon existed. Would you agree that your code is more likely to dissapper now that you don't care about style?
No, I don't think it matters. Obviously there's a line you have to draw, like tabs vs spaces, but I don't care if you place your commas differently from me. Code being so ugly it's hard to read is a problem, but arbitrary fashion is not worth the time.
Not just naming conventions, or assignments in if-clauses, but files there the first indentation level is three spaces, and the rest are all four...
P.S.: And because it's that old, the change-history of a given line can be very important, so it's too late to mass-reformat everything. So you either make the file uglier by mixing "standards", or you have to hand-tweak all your changes to match.