Re:I ruin developers’ lives with my code reviews and I'm sorry
by Hydraulix989 on Monday February 18, 2019 @02:33PM
(#19193567)
It could also be a testament of the reviewer's inability to read code written differently.
Style is not consistent across authors, codebases, projects, even companies. I had to learn to read code in many different styles.
Enforcing consistency can be done with formatters/linters. It doesn't need to come up in review.
Re:I ruin developers’ lives with my code reviews and I'm sorry
by sauceop on Monday February 18, 2019 @02:41PM
(#19193644)
It depends on how important you think it is to optimize for future readers or maintainers of the code. I weigh that pretty heavily and a do think relatively minor style issues impose a tax once they're pervasive in a codebase.
Tooling is great, but I think there are a lot of style issues that aren't readily enforceable with linters - commenting, naming, control flow, abstraction, etc.
Code authors who don't see the value in consistency of code are potentially a problem - if authors are submitting code reviews with hundreds of actual style issues, that's either a failure of process or the author to write readable code (not sure if that's what happened in your examples, to be clear).