3 ms·

Noobie question..... Do you think there is any value in writing the code with the correct style before it is fixed in the compiler? Like is it easier to help

Noobie question..... Do you think there is any value in writing the code with the correct style before it is fixed in the compiler? Like is it easier to help out and spot a problem quicker, if everyone is thinking in the exact same patterns when they write code?

btbuildem 8y ago
If everyone is thinking in the exact same pattern, you will have terrible monoculture, and a total inability to get past certain kinds of problem. An effective team is comprised of people with a variety of backgrounds and approaches.
- akerl_ 8y ago
  This is a very uncharitable interpretation of the parent comment. The parent comment appears to be referring to having people keep the shared style guide in mind when writing code, vs just letting the linter fix it. Extrapolating this to suggesting they don't want a team "with a variety of backgrounds and approaches" drags the conversation pretty far afield of that question.
aequitas 8y ago
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/

btbuildem 8y ago

If everyone is thinking in the exact same pattern, you will have terrible monoculture, and a total inability to get past certain kinds of problem. An effective team is comprised of people with a variety of backgrounds and approaches.

akerl_ 8y ago
This is a very uncharitable interpretation of the parent comment. The parent comment appears to be referring to having people keep the shared style guide in mind when writing code, vs just letting the linter fix it. Extrapolating this to suggesting they don't want a team "with a variety of backgrounds and approaches" drags the conversation pretty far afield of that question.

aequitas 8y ago

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/