3 ms·

> , whether default or customized. This comment comes with the the smell of the idea that there is a right and wrong way to format code, when in fact with, Ruby

> , whether default or customized. This comment comes with the the smell of the idea that there is a right and wrong way to format code, when in fact with, Ruby at least, there's a lot of nuance that can be added in the way the article describes. I'm sorry you smelled that; I don't believe there is one way to do format code, but the opposite. I am saying that working in teams it's convenient to work to the team's style rather than your own particular likes and dislikes. Mainly avoid getting into code review Jenga about style preferences.

wlll 6y ago
I believe there are two problems at play here. 1. Inconsistency causing maintainability/readability problems. 2. The desire to avoid discussions about style within a team. If you're talking about 1. here then what you're talking about is consistency as a tool that can be used to further the goal of maintainability/readability, but as with all tools it can be applied too broadly to problems it doesn't suit, which I would argue includes the subtlety and nuance around the intent of some code rather than the function, and so to force consistency there, and to nullify intent, harms the persuit of the end goal. Point 2. is in my experience so rare that I'm tempted to assume it's just a post-rationalisation used to justify the pleasing sensation programmers get from making things the same. However, assuming it does exist, just in companies I've not experienced, this isn't really a goal that in my opinion is best served by a linter, once you've got to the point that you've automatically fixed all the issues that are obvious (such as lead spaces, syntax errors, security issues etc). Everything you're left with after this point is a programmer either expressing intent, or making an unsound style choice, and this is best solved in code review. Expressing intent is valuable, especially in a language like Ruby where there is room for nuance. If you've got two developers fighting over preferred style, bring in a senior developer to educate about this and perhaps even bring it up in the employee review. If you've got two senior developers who disagree about the style of a piece of code, then they should be expressing their opinions in a non-argumentative and suggestive style: Senior a> "I would prefer to see this code written like this, but this is a personal preference" Senior b> "I wrote it like this to show x intent" or "I have amended the code as you suggested"
ericb 6y ago
> Mainly avoid getting into code review Jenga about style preferences. What about a world where style concerns aren't part of a code review? Style debates provide the superficial appearance of a code review while offering no useful review of security, architecture and intent. I like a super basic stripped down rubocop, and instead of a focus on "style", a more considered focus on readability.

wlll 6y ago

I believe there are two problems at play here. 1. Inconsistency causing maintainability/readability problems. 2. The desire to avoid discussions about style within a team. If you're talking about 1. here then what you're talking about is consistency as a tool that can be used to further the goal of maintainability/readability, but as with all tools it can be applied too broadly to problems it doesn't suit, which I would argue includes the subtlety and nuance around the intent of some code rather than the function, and so to force consistency there, and to nullify intent, harms the persuit of the end goal. Point 2. is in my experience so rare that I'm tempted to assume it's just a post-rationalisation used to justify the pleasing sensation programmers get from making things the same. However, assuming it does exist, just in companies I've not experienced, this isn't really a goal that in my opinion is best served by a linter, once you've got to the point that you've automatically fixed all the issues that are obvious (such as lead spaces, syntax errors, security issues etc). Everything you're left with after this point is a programmer either expressing intent, or making an unsound style choice, and this is best solved in code review. Expressing intent is valuable, especially in a language like Ruby where there is room for nuance. If you've got two developers fighting over preferred style, bring in a senior developer to educate about this and perhaps even bring it up in the employee review. If you've got two senior developers who disagree about the style of a piece of code, then they should be expressing their opinions in a non-argumentative and suggestive style: Senior a> "I would prefer to see this code written like this, but this is a personal preference" Senior b> "I wrote it like this to show x intent" or "I have amended the code as you suggested"

ericb 6y ago

> Mainly avoid getting into code review Jenga about style preferences. What about a world where style concerns aren't part of a code review? Style debates provide the superficial appearance of a code review while offering no useful review of security, architecture and intent. I like a super basic stripped down rubocop, and instead of a focus on "style", a more considered focus on readability.