Hacker News new | ask | show | jobs
by phaedryx 2313 days ago
Every RuboCop rule is reasonable. That is, you can look up the reason and see if you agree or not.

Our team has overridden about a dozen rules (we bumped up line length and class length), but I find most of the default rules are fine.

Out of curiosity, what rules are unreasonable to you?

7 comments

In my opinion the rules about requiring or forbidding parentheses are fairly arbitrary.

Sometimes it's really nice to fit three panes of code on a single laptop screen. Long lines can also indicate a code smell. It's ironic that one of the first things most teams change is the 80 character line length.

I remember having a bug because Rubocop changed 'and' to '&&'. I don't think that a linter should have a rule that breaks the language rules
Yup. `conditional or return fallbackValue`. Rubocop desperately wants to change this to `conditional || return fallbackValue` but that's just.... not a thing.
Not every rule has a reason, some of it is just "because style guide" and if you try to look up the rationale there, you'll find none.

Classic example is Perl style %w(literal arrays) vs ['traditional', 'arrays'].

> Prefer `%w` to the literal array syntax when you need an array of strings

Which was introduced[1] into the style guide nearly 9 years ago with practically no reasoning. Prefer `%w` because why exactly?

[1] https://github.com/rubocop-hq/ruby-style-guide/commit/b27eff...

I prefer the brackets to parens because it makes it more clear at a glance that the result is an array.
Shorter. Different code coloring. I prefer %w where possible with or without Rubocop.
Some rules break Ruby semantics - if you apply their 'rule' you get a program that does something different! I think that's an unreasonable rule.
FWIW, I was just sharing this with someone the other day when discussing the same issue https://gist.github.com/whalesalad/820810f2e969eef816402241a...
Gems in Gemfile ordered alphabetically :/
‘private’ methods forced to be NOT indented.