[NOTE: until StandardRB hits 1.0.0, we consider this configuration to be a
non-final work in progress and we encourage you to submit your opinions (and
reasoned arguments) for the addition, removal, or change to a rule by opening
an issue. If you start using
Standard, don't be shocked if things change a bit!]

Usage

Once you've installed Standard, you should be able to use the standardrb
program. The simplest use case would be checking the style of all Ruby
files in the current working directory:

Note: If you're running Standard in a context where your .standard.yml file
cannot be found by ascending the current working directory (i.e. against a
temporary file buffer in your editor), you can specify the config location with
--config path/to/.standard.yml.

What you might do if you're REALLY clever

Because StandardRB is essentially a wrapper on top of
RuboCop, it will actually forward the
vast majority of CLI and ENV arguments forward to RuboCop.

Adopting Standard style means ranking the importance of code clarity and
community conventions higher than personal style. This might not make sense for
100% of projects and development cultures, however open source can be a hostile
place for newbies. Setting up clear, automated contributor expectations makes a
project healthier.

I disagree with rule X, can you change it?

[NOTE: until StandardRB hits 1.0.0, the answer is yes! It just requires
opening an issue and
convincing @searls (the BDFNow) to make the
change.]

No. The whole point of Standard is to save you time by avoiding
bikeshedding
about code style. There are lots of debates online about tabs vs. spaces, etc.
that will never be resolved. These debates just distract from getting stuff
done. At the end of the day you have to 'just pick something', and that's the
whole philosophy of Standard -- its a bunch of sensible 'just pick something'
opinions. Hopefully, users see the value in that over defending their own
opinions.

Pro tip: Just use Standard and move on. There are actual real problems that
you could spend your time solving! :P

Is there an automatic formatter?

Yes! You can use standardrb --fix to fix most issues automatically.

standardrb --fix is built into standardrb for maximum convenience. Most
problems are fixable, but some errors must be fixed manually.

Can I override the fix: true config setting?

Also yes! You can use standardrb --no-fix. Not fixing is the default behavior, but this flag will override the fix: true setting in your .standard.yml config. This is especially useful for checking your projects compliance with standardrb in CI environments while keeping the fix: true option enabled locally.

How do I ignore files?

Sometimes you need to ignore additional folders or specific minified files. To
do that, add a .standard.yml file to the root of your project and specify a
list of files and globs that should be excluded:

How do I hide a certain warning?

In rare cases, you'll need to break a rule and hide the warning generated by
Standard.

Ruby Standard Style uses RuboCop
under-the-hood and you can hide warnings as you normally would if you used
RuboCop directly.

To ignore only certain rules from certain globs (not recommended, but maybe your
test suite uses a non-standardable DSL, you can specify an array of RuboCop
rules to ignore for a particular glob:

ignore:
- 'test/**/*':
- Style/BlockDelimiters

You can also use special comments to disable all or certain rules within your
source code. See RuboCop's
docs
for details.

How do I specify a Ruby version? What is supported?

Because Standard wraps RuboCop, they share the same runtime
requirements—currently,
that's MRI 2.2 and newer. While Standard can't avoid this runtime requirement,
it does allow you to lint codebases that target Ruby versions older than 2.2 by
narrowing the ruleset somewhat.

Standard will default to telling RuboCop to target the currently running version
of Ruby (by inspecting RUBY_VERSION at runtime. But if you want to lock it
down, you can specify ruby_version in .standard.yml.

It's a little confusing to consider, but the targeted Ruby version for linting
may or may not match the version of the runtime (suppose you're on Ruby 2.5.1,
but your library supports Ruby 2.2.0). In this case, specify ruby_version and
you should be okay. However, note that if you target a newer Ruby version than
the runtime, RuboCop may behave in surprising or inconsistent ways.

If you are targeting a Ruby older than 2.2 and run into an issue, check out
Standard's version-specific RuboCop
configurations and
consider helping out by submitting a pull request if you find a rule that won't
work for older Rubies.

How do I change the output?

Standard's built-in formatter is intentionally minimal, printing only unfixed
failures or (when successful) printing nothing at all. If you'd like to use a
different formatter, you can specify any of RuboCop's built-in formatters or
write your own.

For example, if you'd like to see colorful progress dots, you can either run
Standard with: