3 ms·
I've not noticed any correlation either. If it's actually useful, which it may be, the degree of usefulness seems to be slight enough that it just gets lost in
by to3m 14y ago
I've not noticed any correlation either. If it's actually useful, which it may be, the degree of usefulness seems to be slight enough that it just gets lost in the noise.
I guess people like this stuff because it's easy to check for, and easy to explain, and everybody's been annoyed by inconsistent code layout before, to one extent or another, so it can be an easy sell. It might also function as starter rules, getting a wayward team used to the simple idea of all working the same way, something that can be further extended in the future with more rigorous rule sets.
It must be something like that, anyway, because I have to say that it doesn't seem to do anything for the actual quality of the code. I've torn my hair out in frustration over beautifully consistent code just as much as I have over the stuff that looks like a test case for a C parser - and it's precious little consolation if the stupid braces are in the same place on every line.
- df3n5 14y agoThis is true - there is a definite distinction that should be made between style and code quality. Good code could be ofuscated and it would still be good code. I don't think converting bad quality code to good quality code is something that can be automated. It should be something that is caught by code review and be flagged for discussion with the whole team if it is a general anti-pattern which is emerging in the codebase. When patterns / anti-patterns are observed, I think they should be called out and documented for future reference. This over time will lead to general coding guidelines, which are way more important than consistent syntax, as they should mitigate the hair pulling sessions you describe.