3 ms·

Depends on the kind of style 'subject' I think. If it is trivial indentation, bracket placement and other preference kind of things it probably wouldn't. But if

Depends on the kind of style 'subject' I think. If it is trivial indentation, bracket placement and other preference kind of things it probably wouldn't. But if the style things lean more towards design patterns, then often there is a proper reason behind choosing that style over another and it would help because you would notice doing it the 'wrong' way and you stop to evaluate and maybe spot a bug or design issue. I think that would fall in the category of code smells like when you use a framework in a convoluted way you're probably not using the framework right or over stretching it.

Jach 8y ago
I'd second this. Depending on the style in question, there could be a mismatch in thinking, but probably not for most styles. If you're used to writing very dense C code for example, transforming it at the end to meet typical Enterprise Java standards might introduce subtle logic issues (or point out existing ones) or make it harder for you to understand in the future depending on how the transformation is done, but this is really just another instance of the general refactor caution to lean on tools, incremental changes that preserve key features like function signatures, and tests to make certain you don't change behavior. Styles like forbidding single-statement if conditions that don't have curly braces helps protect you from bugs like goto-fail[0] meanwhile styles like which line your opening curly goes on, use of spacing, dare I say tabs vs spaces (outside of languages with significant whitespace anyway), and even abbrev names vs BigLongNames[1] don't really matter apart from personal preference and it being aesthetically pleasing to have local consistency. [0] https://www.imperialviolet.org/2014/02/22/applebug.html https://www.imperialviolet.org/2014/02/22/applebug.html [1] https://www.hillelwayne.com/post/the-best-se-paper/ https://www.hillelwayne.com/post/the-best-se-paper/

Jach 8y ago

I'd second this. Depending on the style in question, there could be a mismatch in thinking, but probably not for most styles. If you're used to writing very dense C code for example, transforming it at the end to meet typical Enterprise Java standards might introduce subtle logic issues (or point out existing ones) or make it harder for you to understand in the future depending on how the transformation is done, but this is really just another instance of the general refactor caution to lean on tools, incremental changes that preserve key features like function signatures, and tests to make certain you don't change behavior. Styles like forbidding single-statement if conditions that don't have curly braces helps protect you from bugs like goto-fail[0] meanwhile styles like which line your opening curly goes on, use of spacing, dare I say tabs vs spaces (outside of languages with significant whitespace anyway), and even abbrev names vs BigLongNames[1] don't really matter apart from personal preference and it being aesthetically pleasing to have local consistency. [0] https://www.imperialviolet.org/2014/02/22/applebug.html https://www.imperialviolet.org/2014/02/22/applebug.html [1] https://www.hillelwayne.com/post/the-best-se-paper/ https://www.hillelwayne.com/post/the-best-se-paper/