standard

Hopefully rubocop-rails-omakase [1] will pull in stuff like this. I've gone from custom Rubocop rules in various projects to just using rubocop-rails-omakase, which finally feels like a consensus of sorts. I think Standard [2] is harmfully redundant, personally. [1] https://github.com/rails/rubocop-rails-omakase [2] https://github.com/standardrb/standard

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

(this is probably unfairly cynical but), reading heavily between the lines, this reads to me like DHH noticed lots of Rails folks and rubyists already like and use "standardrb" for this https://github.com/standardrb/standard -- https://www.youtube.com/watch?v=QVilOzkLdlI -- but for some (unspecified?) reason(s), wasn't willing to bless the popular community-created universal standard as default convention, so instead wrote up his own, and is declaring his the default convention for Rails.

This is a huge reason why I still use StandardJS and—shifting back to Ruby—why I rejected the countless requests for implementing line-length or any other metrics analysis rules for Standard Ruby (https://github.com/standardrb/standard). There is always a legitimate edge case when it comes to length of lines and functions and the alternative—chopping them off arbitrarily—is rarely an improvement.

As someone who has been doing Ruby for 20 years, the bbatsov style guide is bonkers. Rubocop can be good, but it needs too much configuration to make it not follow bbatsov guide — which is simply wrong on a number of levels. Recently, I’ve started using https://github.com/testdouble/standard as a wrapper around Rubocop. It is both less and more opinionated than Rubocop, but aside from two style choices (`%w[]` — using `[]` there is legal but not idiomatic Ruby IMO; I also prefer terminal dots rather than leading dots (e.g., `foo.\nbar` instead of `foo\n.bar`), it doesn’t bother me nearly as much as Rubocop’s defaults do. There are many things that Rubocop gets wrong in its defaults. The absolute single #1 thing it gets wrong is markers. It sort-of supports the only useful distinction, laid out by Jim Weirich (`foo {}` when block return va

You should have a look at Standard Ruby https://github.com/testdouble/standard In particular, a lot from the lightning talk resonates with me.

See also, the "StandardRB" wrapper around somebody's RuboCop config: https://github.com/testdouble/standard https://github.com/testdouble/standard/blob/main/config/base...

I personally like standardrb (https://github.com/testdouble/standard). It is a set of sane defaults that I agree with mostly. Standard was also complaining a little but omitting the explicit else branch made it happy. Anyways you can customize RuboCop to your likings, use standardrb that comes with a lot of carefully considered defaults and uses RuboCop under the hood or don't use a linter at all and move on with your life.

This is exactly nice about it. With Rubocop standardrb (https://github.com/testdouble/standard) has a solid foundation to make everyone's live easy.

There's also StandardRB, it's like StandardJS but for ruby: https://github.com/testdouble/standard Lightning talk about it here: https://www.youtube.com/watch?v=uLyV5hOqGQ8 Edit: I posted it on its own if you want to discuss: https://news.ycombinator.com/item?id=20186231