4 ms·

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.

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.

Terr_ 9y ago
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.
alextheparrot 9y ago
Manual linting is silly, but having a linter installed really saves a lot of pain. Git diffs should not include unrelated linting changes.
- artursapek 9y ago
  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.
  - dasil003 9y ago
    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.
- sebcat 9y ago
  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. [1] http://clang.llvm.org/docs/ClangFormat.html#script-for-patch-reformatting http://clang.llvm.org/docs/ClangFormat.html#script-for-patch...
emiliobumachar 9y ago
Relevant smbc: http://www.smbc-comics.com/?id=2461 http://www.smbc-comics.com/?id=2461
- artursapek 9y ago
  How is that relevant
  - emiliobumachar 9y ago
    The parent to my original post is an example of exigology. Paraphrasing: "My code will be gone next year, so I don't care about code style"
    - artursapek 9y ago
      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.
      - emiliobumachar 9y ago
        > 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?

Terr_ 9y ago

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.

alextheparrot 9y ago

Manual linting is silly, but having a linter installed really saves a lot of pain. Git diffs should not include unrelated linting changes.

artursapek 9y ago
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.
- dasil003 9y ago
  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.
sebcat 9y ago
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. [1] http://clang.llvm.org/docs/ClangFormat.html#script-for-patch-reformatting http://clang.llvm.org/docs/ClangFormat.html#script-for-patch...

emiliobumachar 9y ago

Relevant smbc: http://www.smbc-comics.com/?id=2461 http://www.smbc-comics.com/?id=2461

artursapek 9y ago
How is that relevant
- emiliobumachar 9y ago
  The parent to my original post is an example of exigology. Paraphrasing: "My code will be gone next year, so I don't care about code style"
  - artursapek 9y ago
    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.
    - emiliobumachar 9y ago
      > 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?