|Project Name||Stars||Downloads||Repos Using This||Packages Using This||Most Recent Commit||Total Releases||Latest Release||Open Issues||License||Language|
|Standard||2,323||19 hours ago||25||other||Ruby|
|Ruby's bikeshed-proof linter and formatter 🚲|
|Rufo||814||53||42||a month ago||56||May 09, 2021||28||mit||Ruby|
|The Ruby Formatter|
|Rubocop Checkstyle_formatter||62||319||42||9 months ago||12||August 19, 2021||1||mit||Ruby|
|A rubocop formatter that outputs in checkstyle format|
|Rubocop Junit Formatter||9||5 years ago||6||mit||Ruby|
|Vim Rubocop||7||4 years ago||mit||Vim script|
|Run rubocop async|
|Rubocop Github Annotations Formatter||7||3 years ago||1||January 28, 2020||mit||Ruby|
|Format Rubocop output for Github Annotations|
|Sublime Codefmt||5||4 months ago||1||Python|
|A Sublime Text plugin that allows applying code formatting with minimum configuration.|
|Generate a configuration file acting as a TODO list|
|Rubocop Junit_formatter||5||2 years ago||mit||Ruby|
|A JUnit Formatter for RuboCop|
|Coding Style||4||2 years ago||Ruby|
|Our preferred formatting style and best practices|
standard gem brings the ethos of StandardJS to
Ruby. It's a linter & formatter built on
RuboCop and provides an unconfigurable
configuration to all of RuboCop's built-in rules as well as those included in
rubocop-performance. It also
supports plugins built with
Standard Ruby was created and is maintained by the team at Test Double, because we appreciate the importance of balancing predictable, consistent code with preserving developer autonomy.
Topics covered in this README:
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 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 is time wasted.
But you can't configure Standard Ruby. You can take it or leave it. If this seems presumptive, constraining, and brusque: you're right, it usually does feel that way at first. But since 2018, the Ruby community has debated Standard Ruby's ruleset, ultimately landing us on a sensible set of defaults that_while no one person's favorite way to format Ruby_seems to be good enough for most of the ways people use Ruby, most of the time.
If you adopt Standard Ruby, what's in it for you? Time saved that would've been spent arguing over how to set things up. Also, seamless upgrades: we stay on top of each new RuboCop rule and update our configuration on a monthly release cadence. But the best part of adopting Standard as your linter and formatter? You'll spend a whole lot less time thinking about linters and formatters.
So please, give Standard Ruby a try. If you're like these folks, you'll soon realize that the value of a linter is in using one at all and not in the particulars of how it's configured.
Getting started is as easy as
gem install standard or throwing it in your
gem "standard", group: [:development, :test]
Once installed, you can either run it as a CLI or as a Rake task.
The CLI is called
standardrb to distinguish it from
And the Rake task can be run if your Rakefile includes
require "standard/rake". This will load the
standard task, allowing you to run:
$ rake standard
Either way, Standard will inspect any Ruby files found in the current directory tree. If any errors are found, it'll report them. If your code is standard-compliant, it will get out of your way by quietly exiting code 0.
A majority of Standard's rules can be safely fixed automatically.
# CLI $ standardrb --fix # Rake $ rake standard:fix
Because we're confident Standard's fixes won't change the behavior of our code, we typically run with fix enabled all the time because it saves us from having to look at and think about problems the computer can solve for us.
There are a number of other rules that can be automatically remedied, but not without the risk of changing your code's behavior. While we wouldn't recommend running it all the time, if the CLI suggests that additional errors can be fixed unsafely, here's how to do that:
# CLI $ standardrb --fix-unsafely # Rake $ rake standard:fix_unsafely
So long as your code is checked into source control, there's no mortal harm in running with unsafe fixes enabled. If the changes look good to you and your tests pass, then it's probably less error prone than manually editing everything by hand.
Because code formatting is so integral to programming productivity and linter violations risk becoming bugs if released into production, tools like Standard Ruby are only as useful as their integration into code editors and continuous integration systems.
We've added a number of editing guides for getting started:
If you'd like to help by creating a guide, please draft one in an issue and we'll get it added!
If you don't see your preferred editor above, Standard Ruby also ships with a built-in language server that many modern editors can support natively, even without a Standard-specific plugin.
You can run the server by supplying the
If your editor offers LSP support, it probably has a place to configure the above command and will subsequently manage the server process for you.
Various continuous integration and quality-checking tools have been made to support Standard Ruby, as well.
Of course, no special plugin is necessary to run Standard Ruby in a CI
rake standard work just fine on their own!
These tool integrations are also available:
While Standard is very strict in how each formatting and linting rule is configured, it's mercifully flexible when you need to ignore a violation to focus on a higher priority (like, say, keeping the build running). There are a number of ways to ignore any errors, with the right answer depending on the situation.
Individual lines can be ignored with a comment directive at the end of the line.
As an example, the line
text = 'hi' violates two rules,
You could ignore one, both, or all errors with the following comments:
# Disable one error but keep Lint/UselessAssignment text = 'hi' # standard:disable Style/StringLiterals # Disable both errors explicitly text = 'hi' # standard:disable Style/StringLiterals, Lint/UselessAssignment # Disable all errors on the line with "all" text = "hi" # standard:disable all
Similarly to individual lines, you can also disable multiple lines by wrapping them in comments that disable and re-enable them:
# standard:disable Style/StringLiterals, Lint/UselessAssignment text = "hi" puts 'bye' # standard:enable Style/StringLiterals, Lint/UselessAssignment
You can ignore entire files and file patterns by adding them to
ignore: - 'some/file/in/particular.rb' - 'a/whole/directory/**/*'
For a given file or glob, you can even ignore only specific rules by nesting an array of the rules you'd like to ignore:
ignore: - 'test/**/*': - Layout/AlignHash
If you're adopting Standard in a large codebase and you don't want to convert everything all at once, you can work incrementally by generating a "todo" file which will cause Standard to ignore every violation present in each file of the codebase.
This way, you can gradually work through the todo list, removing ignore directives and fixing any associated errors, while also being alerted to any regressions if they're introduced into the project.
Here are the commands you might run to get started:
# Start by clearing any auto-fixable errors: $ standardrb --fix # Generate a `.standard_todo.yml' to work from $ standardrb --generate-todo
While the rules aren't configurable, Standard offers a number of options that can be configured as CLI flags and YAML properties.
The easiest way to summarize the available CLI flags is to invoke
Usage: standardrb [--fix] [--lsp] [-vh] [--format <name>] [--] [FILE]... Options: --fix Apply automatic fixes that we're confident won't break your code --fix-unsafely Apply even more fixes, including some that may change code behavior --no-fix Do not automatically fix failures --format <name> Format output with any RuboCop formatter (e.g. "json") --generate-todo Create a .standard_todo.yml that lists all the files that contain errors --lsp Start a LSP server listening on STDIN -v, --version Print the version of Standard -V, --verbose-version Print the version of Standard and its dependencies. -h, --help Print this message FILE Files to lint [default: ./] Standard also forwards most CLI arguments to RuboCop. To see them, run: $ rubocop --help
If you run Standard via Rake, you can specify your CLI flags in an environment
STANDARDOPTS like so:
$ rake standard STANDARDOPTS="--format progress"
In addition to CLI flags, Standard will search for a
(ascending to parent directories if the current working directory doesn't
contain one). If you find yourself repeatedly running Standard with the same
CLI options, it probably makes more sense to set it once in a YAML file:
fix: true # default: false parallel: true # default: false format: progress # default: Standard::Formatter ruby_version: 3.0 # default: RUBY_VERSION default_ignores: false # default: true ignore: # default:  - 'vendor/**/*' plugins: # default:  - standard-rails extend_config: # default:  - .standard_ext.yml
One notable YAML setting is
ruby_version, which allows you to set the oldest
version of Ruby the project needs to support RuboCop's
explicitly. Because this value is inferred from any
*.gemspec files that might be present,
most applications won't need to set this.
However, gems and libraries that support older versions of Ruby will want
to lock the
ruby-version: explicitly in their
.standard.yml file to ensure
new rules don't break old rubies:
Standard includes two extension mechanisms: plugins and configuration extensions. While neither can change the rules configured out-of-the-box by Standard, they can define, require, and configure additional RuboCop rules.
Both are "first-in-wins", meaning once a rule is configured by a plugin or extension, it can't be changed or reconfigured by a later plugin or extension. This way, each Standard plugin you add becomes a de facto "standard" of its own. Plugins have precedence over extensions as they are loaded first.
Adding a plugin to your project is as easy as adding it to your Gemfile and
specifying it in
.standard.yml in the root of your project. For example, after
installing standard-rails, you
can configure it by adding it to
plugins: - standard-rails
Each plugin can be passed configuration options by specifying them in a nested
hash. For example,
standard-rails allows you to configure its rules for
a particular version of Rails (though this will usually be detected for you
plugins: - standard-rails: target_rails_version: 7.0
You can develop your own plugins, too! Check out the lint_roller gem to learn how. For a simple example, you can look at standard-custom, which is one of the default plugins included by Standard.
Of course, you may want to add more rules without going to the trouble
of packaging them in a plugin gem. For cases like this, you can define one or
more RuboCop configuration
files and then list them
.standard.yml file under
For example, after installing the
betterlint gem from our friends at
Betterment, we could create a RuboCop config
require: - rubocop/cop/betterment.rb Betterment/UnscopedFind: Enabled: true unauthenticated_models: - SystemConfiguration
And then reference it in our
extend_config: - .betterlint.yml
Please note that the following usage is not supported and may break at any
time. Use at your own risk and please refrain from opening GitHub issues with
respect to loading Standard or its plugins' YAML configurations for use by
If you find that neither plugins or configuration extensions meet your needs or if you have some other reason to run Standard's rules with RuboCop's CLI (e.g., to continue using your favorite IDE/tooling/workflow with RuboCop support) Evil Martians also maintains a regularly updated guide on how to configure RuboCop to load and execute Standard's ruleset.
In short, you can configure this in your
.rubocop.yml to load Standard's three
default rulesets, just as you would any other gem:
require: - standard - rubocop-performance inherit_gem: standard: config/base.yml standard-performance: config/base.yml standard-custom: config/base.yml
Here are a few examples of Ruby Standard-compliant teams & projects:
Does your team use Standard? Add your name to the list!
If you really want to show off, you can also add a badge to your project's README, like this one:
[![Ruby Code Style](https://img.shields.io/badge/code_style-standard-brightgreen.svg)](https://github.com/standardrb/standard)
This project follows Test Double's code of conduct for all community interactions, including (but not limited to) one-on-one communications, public posts/comments, code reviews, pull requests, and GitHub issues. If violations occur, Test Double will take any action they deem appropriate for the infraction, up to and including blocking a user from the organization's repositories.