Comment by devin | Hacker News Reader

Comment by devin | Hacker News Reader

Parent Full thread

I noped out at "Rubocop makes things better". It seems I'm not the only one in these comments who has encountered rubocop config gatekeepers. It seems there's always one person who vigorously defends some stylistic choice by claiming "for performance", "for readability", etc. until the rest of the team gets tired of arguing about the color of the bike shed and moves on to doing the actual work.

Sometimes I encounter code and go "I think I know who wrote this", and I don't have any problem with that. That's fine. People should have some freedom in the way they write code. A lot of the things I've learned in programming came from saying "ugh, I don't like this", and then later going "oh, that actually makes a lot of sense, and I'm going to adopt it".

I doubt very much there is any real developer time savings attached to enforced subjective uniformity, and in the case of rubocop I would say that the amount of time I've seen people changing this and that to satisfy the linter when what they wrote read just fine, it's probably the opposite.

Interesting; I thought it does the opposite- remove the bike shedding talk.

It does sometimes recommend things that I don’t agree with sometimes, but in exchange I don’t have discussions about style on a PR, which makes it worth it. That’s objectively less time spent talking about these things.

There are two parts to Rubocop, one of which is good. The good part is the engine. The not so good part is the defaults, many of which are wrong and many more of which are "not even wrong" (which is to say that they are enforcing a particularly unidiomatic way of shaping the code based on unimaginative ideas of what good code is supposed to look like).

If you want to eliminate most discussions about code formatting and have a useful subset, use standardrb[1]. I disagree with about a third of its recommendations, but I stopped configuring with standard, whereas I had an override list at least thirty rules long (that had to be updated periodically because of incessant patch version renaming of rules) with vanilla Rubocop.

Rubocop's engine is good. Rubocop's default rules are best avoided and replaced entirely with standard, because they are at least mostly sensible and still allow for "style".

[1] https://github.com/standardrb/standard

Rubocop is better than a free-for-all though. I'm more happy with a any config at all than people trying to rehash the same style of arguments in each PR. Or worse, ending in either a mess of formatting or each change changing unrelated lines just to reformat.

I really believe it's the least bad solution to just get any config and ignore the bikesheding (or drop people who spend too much time on it)

That sounds like a team problem and not a tool problem. We do just fine with it (using rule configs that make sense) and uniformity isn’t the point. If somebody wants something changed for a legitimate reason then it is not a big deal.

You can also have different rules for different folders or files, and toggle rules on or off by line, block, or files.

The part about people spending significant time fixing linter errors sounds suspicious though. That doesn’t seem normal at all. Have they heard of format-on-save, or is there a lack of communication?

I have a problem with the whole layout namespace of rubocop.

Then on top of that there are some rubocop extensions, the rspec one especially, that forces you to write bad, unreadable tests with the worst performance footprints. So unless you are in a company with a good culture where that talk does happen, I would keep rubocop for security sections.

In rspec it forces everything in a let, with single expect per test, so you can never check if two things are set to something at the same time

Theres a rubocop that disallows more than 5 or 6 function parameters. And since there’s nothing very lightweight like ADTs, people just move things to object state :(

Very sad.

If your team disagrees with this rule (or any other one), why wouldn't you just update the rule to match your expectations rather than dismiss the whole tool?

I joined this codebase 10 years into it. We could turn it off now, but the damage is already done.

The problem is that is one example of MANY you will run into issues with.

Reply on news.ycombinator.com