standard

<img src="https://user-images.githubusercontent.com/79303/233717126-9fd13e6d-9a66-4f1c-b40c-fe875cb1d1b4.png" style="width: 100%"/>

[![Tests](https://github.com/standardrb/standard/actions/workflows/test.yml/badge.svg)](https://github.com/standardrb/standard/actions/workflows/test.yml)
[![Ruby Style Guide](https://img.shields.io/badge/code_style-standard-brightgreen.svg)](https://github.com/standardrb/standard)
[![Gem Version](https://badge.fury.io/rb/standard.svg)](https://rubygems.org/gems/standard)

The `standard` gem brings the ethos of [StandardJS](https://standardjs.com) to
Ruby. It's a linter & formatter built on
[RuboCop](https://github.com/rubocop/rubocop) and provides an **unconfigurable
configuration** to all of RuboCop's built-in rules as well as those included in
[rubocop-performance](https://github.com/rubocop/rubocop-performance). It also
supports plugins built with
[lint_roller](https://github.com/standardrb/lint_roller), like
[standard-rails](https://github.com/standardrb/standard-rails) and
[standard-sorbet](https://github.com/standardrb/standard-sorbet).

Standard Ruby was created and is maintained by the team at [Test
Double](https://testdouble.com), because we appreciate the importance of
balancing predictable, consistent code with preserving developer autonomy. 💚

Topics covered in this README:

* [Wait, what?!](#wait-did-you-say-unconfigurable-configuration)
* [Basic usage](#usage)
* [Editor & CI integrations](#integrating-standard-into-your-workflow)
* [Ignoring errors](#ignoring-errors)
* [Configuration options](#configuring-standard)
* [Plugins and extensions](#extending-standard)
* [Community](#who-uses-standard-ruby)

## Wait, did you say unconfigurable configuration?

Yes, Standard is unconfigurable. See, pretty much every developer can agree that
automatically identifying and fixing slow, insecure, and error-prone code is a
good idea. People also agree it's easier to work in codebases that exhibit a
consistent style and format. So, what's the problem? **No two developers will
ever agree on what all the rules and format should be.**

This has resulted in innumerable teams arguing about how to configure their linters
and formatters over literal decades. Some teams routinely divert time and energy
from whatever they're building to reach consensus on where commas should go.
Other teams have an overzealous tech lead who sets up everything _his favorite
way_ and then imposes his will on others. It's not uncommon to witness
passive-aggressive programmers change a contentious rule back-and-forth,
resulting in both acrimony and git churn (and acrimony _about_ git churn).
Still, most developers give way to whoever cares more, often resulting in an
inconsistent configuration that nobody understands and isn't kept up-to-date
with changes to their linter and its target language. Whatever the approach,
time spent
[bikeshedding](https://blog.testdouble.com/posts/2019-09-17-bike-shed-history/)
is time wasted.

**But you can't confi