5 ms·

Of no one will ever agree with every choice made by a linter, whether default or customized. I would rather work in a team that agrees to follow some set of con

Of no one will ever agree with every choice made by a linter, whether default or customized. I would rather work in a team that agrees to follow some set of conventions than than one in which everyone does things the way they prefer personally. For the examples in the post, by all means discuss as a team and agree to exclude them.

bhaak 6y ago
Good defaults are important. It is more difficult to find an agreement over changing a default than configuring a missing configuration option. Last time I raised a formatting change with our team, I got replies like "the default settings have been agreed with the community"(a blatant lie) or "I wasted enough time in my life discussing formatting" (okay, this guy has to write C# mostly, the standard formatting is already a lost cause there anyway).
- paublyrne 6y ago
  Agree that can be an issue. Often it's not worth the energy doing that. But without the linter there's a good chance you'll end up discussing the formatting in code review which doesn't really benefit anyone.
wlll 6y ago
> Of no one will ever agree with every choice made by a linter, 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. There are legitimate reasons for expressing the same functionality of code in different ways to express intent, something that Rubocop unfortunately isn't able to judge. > I would rather work in a team that agrees to follow some set of conventions than than one in which everyone does things the way they prefer personally. These aren't the only two options, there is a middle ground, in which you use cops that solve problems that are unambiguous, such as tabs/spaces for initial indentation, which brings me to the next point: > For the examples in the post, by all means discuss as a team and agree to exclude them. My main problem with Rubocop (which is a great tool) is that everything is enabled by default (and this seems to be encouraged) and the tool is overused. To me Rubocop smacks of the classic programmer problem of discovering you can do something, and so applying the solution to all the places the solution can be applied. "Because we can, not because we should".
- paublyrne 6y ago
  > , 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"
  - 6y ago

bhaak 6y ago

Good defaults are important. It is more difficult to find an agreement over changing a default than configuring a missing configuration option. Last time I raised a formatting change with our team, I got replies like "the default settings have been agreed with the community"(a blatant lie) or "I wasted enough time in my life discussing formatting" (okay, this guy has to write C# mostly, the standard formatting is already a lost cause there anyway).

paublyrne 6y ago
Agree that can be an issue. Often it's not worth the energy doing that. But without the linter there's a good chance you'll end up discussing the formatting in code review which doesn't really benefit anyone.

wlll 6y ago

> Of no one will ever agree with every choice made by a linter, 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. There are legitimate reasons for expressing the same functionality of code in different ways to express intent, something that Rubocop unfortunately isn't able to judge. > I would rather work in a team that agrees to follow some set of conventions than than one in which everyone does things the way they prefer personally. These aren't the only two options, there is a middle ground, in which you use cops that solve problems that are unambiguous, such as tabs/spaces for initial indentation, which brings me to the next point: > For the examples in the post, by all means discuss as a team and agree to exclude them. My main problem with Rubocop (which is a great tool) is that everything is enabled by default (and this seems to be encouraged) and the tool is overused. To me Rubocop smacks of the classic programmer problem of discovering you can do something, and so applying the solution to all the places the solution can be applied. "Because we can, not because we should".

paublyrne 6y ago
> , 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"
- 6y ago