Inside the decision room: How Standard Ruby updates its rules

It’s been six years since Justin Searls, our co-founder, announced Standard Ruby at RubyConf 2018. Since then, the team at Test Double has continually kept Standard Ruby up-to-date with the latest rules and tools that RuboCop offers.

In the last six years, Standard has:

• been downloaded 19 million times,
• been used to maintain hundreds of Ruby projects,
• extended into a Visual Studio Code extension,
• turned into a plugin architecture so more common Ruby libraries can be standardized,
• and extended into a Github Action to get into your CI flow,
• been included in books about Rails programming! 

That’s all well and good, but one question persists: How does Standard Ruby get updated? How does the team at Test Double decide which RuboCop rules go in and which RuboCop rules get the boot?

Well, at RailsConf 2023, the process was out in the open, when Justin Searls and Double Agent Meagan Waller ran a town hall vote-a-rama to build out a set of rules for standard-rails.

But what happens the rest of the time?

How often does Standard get updates?

First thing to understand is the cadence. We chose a pretty simple rhythm. Every month, a group at Test Double gets together to upgrade the Standard family of plugins.

Two get priority: Standard, itself, and Standard Performance, so you should definitely expect those two to get up to date with RuboCop and RuboCop Performance every month. Others, like Standard Rails or Standard Sorbet, may skip months.

Hey, you said “the team,” but who’s that?

Well, like any open source project, Standard Ruby gets contributions from the community, but the maintainers of the project over the years have been Justin Searls, Jennifer Konikowski, and Camilo Payan.

Currently the monthly meetup to update Standard Ruby is run with Craig Zeise, Robby Thompson, and Jason Karns. You can always keep up to date with Standard updates by following them on social media!

How do you decide what goes in and out?

I went back and looked through my past conversations with Justin Searls and Jennifer Konikowski to distill the ethos of Standard Ruby:

‍Don’t break code! In practice, this means that unsafe autocorrects should be avoided, since a false positive could break your app. Cribbing from healthcare: “First, do no harm.”

‍Make the code easier to read. The fact is, a lot of this is down to taste, but this is one of the main watchwords of Standard Ruby. It’s Jennifer’s first question: “Will this make the code easier to read?” Justin mirrored the same criteria for a rule: “Would generally promote Ruby code that is agreeable as conventional, more readable.”

‍Keep the change sets small. The fact is that no one wants to suddenly get a pile of busy work from their linter just because they did the right thing and kept it up to date. We aim to include rules that we don’t think will trigger a huge amount of errors to fix. Obviously, the first time you use Standard Ruby is different. Like with any linter, you’re bound to get a lot of errors. We work to pick safe autofixers so hopefully a quick “standardrb –fix” will take care of most of the work for you!

‍Can be applied to all of Ruby. There’s more to life than Rails apps! Standard Ruby is for all the major use cases for Ruby, including shell scripts, gems, DSLs, etc. We want rule sets that won’t break those cases either.

‍Lower errors. Test Double has a mission to improve the way the world builds software, and Standard is just one of the ways we work toward that end. We want rules that simplify code to make it more understandable and less error-prone, as well as making Ruby easier to work with bug-free.

‍Keep up with the latest Ruby features. When possible, we opt to enable rules that encourage Ruby developers to use the latest features in the Ruby language. They can be more readable and more performant, and generally it’s always nice to have something automated do that for you!

‍Don’t spawn more bikeshedding debates. Coming up with style guides and linter configurations team by team has wasted countless hours of developer time in the nitty gritty details. The main point of Standard Ruby has always been to save everyone’s sanity by giving a reasonable “standard” config that doesn’t need to be maintained by every individual team on the planet. That would go right out the window if we took opinions on rules that are extremely selective case-by-case, such as RuboCop’s line length or method length rules. You probably have a good reason for the 200-character line, and we don’t want to hear about it!

What do you do if you don’t like Standard Ruby’s decisions?

Did you try it out? Did you give it a real chance? Was it really that bad?

"I really don’t like it! Let me out!"

Okay, so Standard Ruby is not configurable by design. If you think that we’re not really following the criteria above, please make an issue and we can talk about it.

Otherwise, RuboCop strives to create rules for all situations, but Standard Ruby strives to lock those down to an agreeable subset. You might just need RuboCop and not Standard! After all, Standard is standardized; your code might not be.

Here’s to six more years of standardizing Ruby, and remember, although each codebase may be miserable in its own way, that doesn’t mean you can’t improve onboarding, readability, and performance with Standard Ruby! Do it now! Go!