What Is RuboCop for Ruby?

First, RuboCop is a great tool to lint a code base and ensure a specific coding style is followed (such as indentation, spacing, naming conventions, etc.). It's heavily configurable on that level through many rules, called "cops". Each can be activated (or not) and tailored (for example, the number of characters per line).

The second side of RuboCop is its ability to analyze code statically for quick insights into code complexity and potential code issues, such as the misuse of variables.

As RuboCop is a little utility, it's easily run within a CI pipeline and in any developer's IDE. Thus, RuboCop's feedback can be integrated into the key places where it matters: when code is being written and before it's merged into the code base.

How to Use RuboCop for Ruby

Style is a matter of taste, so it is entirely subjective. Remember the main point behind using a linter: it's just there to help follow a chosen style because it gives us more capacity to do what matters in any project.

By default, RuboCop will enforce the style defined in the Ruby Community Style Guide. We can tailor it to our specific tastes and context, but let's rely on this basic set of rules to learn how to use RuboCop.

Simple Use of RuboCop

Adding RuboCop to a project is as simple as adding the rubocop gem to the development and test group in the Gemfile. 

group :development, :test do
  gem 'rubocop', require: false
end

$> rubocop *

$> rubocop *
Inspecting 807 files
...CCC....................
Offenses:
app/controllers/api/messages_controller.rb:46:25: C: Naming/MethodParameterName: Method parameter must be at least 3 characters long.
80 files inspected, 20 offenses detected, 7 offenses autocorrectable

Layout/LineLength:
  Max: 99

Naming/MethodParameterName:
  MinNameLength: 3
  AllowedNames:
    - as
    - at
    - in
    - ip
    - id
    - to

 # rubocop:disable Layout/ClassStructure, Style/AndOr
[...]
# rubocop:enable Layout/ClassStructure, Style/AndOr

# rubocop:disable all
[...]
# rubocop:enable all

RuboCop in Practice

Now that we have seen what it is and how to use it, let's review how we might use RuboCop in our day to day.

Local Uses

As discussed before, a linter's purpose is to ensure a standard style is used throughout a code base. Standards are how we help each other work together without putting up complex conversion and compensation schemes. When building a house, standards are the way every carpenter knows how to work together. The actual details will be a bit different from one house to another, but, using the standard, the work different carpenters do will match.

RuboCop helps software engineers work together by keeping their code up to a certain standard style.

The simplest way to use RuboCop is to run it before making a commit or once in a while before pushing commits to a remote repository. As described in the first part of this post, using rubocop * will run a check of the code base and display any offenses for you to fix.

You can then use the -a or -A option on another run to get some or all offenses fixed by RuboCop.

$> rubocopo -a

 You can also fix them yourself, of course.

Within an IDE

Some IDEs and text editors have RuboCop plugins, so you can get notices about style offenses while working directly on code. The only issue with these is the configuration, which can be fiddly.

Integration with CI

It's important to run RuboCop within CI pipelines.

Usually, we run linters such as RuboCop as part of a pipeline's first steps to notify the author of code changes about any offense quickly. We also consider such infractions important, so they will block the Pull or Merge request in its tracks. A merge should not be possible if the style is not correct.

If your project relies on GitHub's Actions, you can find a RuboCop action. You can build similar steps for any CI/CD pipeline out there. The principle is simple: run RuboCop against the code base as an early block within the pipeline; if there is an infraction, it will return a non-zero code, and the CI will treat that as a failure. The output can be used more easily as an artifact.

The -f option will allow you to tailor the output format. This can be practical when running RuboCop in the CI pipeline: in markdown, HTML, or GitHub. I'd advise starting with markdown or HTML, but you should also consider the fairly readable default format.

Wrapping Up

RuboCop is, alongside Bundler, a good friend to any Ruby developer. As we have seen, it's easy to run it locally to get a list of offenses against a project's style standard.

We have also seen how RuboCop can fix a lot of those offenses on its own, and how to work our way through a long list of offenses if we start from a large backlog.

RuboCop is a tool in your toolbox; code style is only meant to help a team work together and shouldn't be a perpetual topic of debate. Yet, we have also seen that if you find it tedious to figure out a style for your project, you should look into projects such as Standard Ruby.

swaz_ahmed

I am swaz_ahmed blogger on shadbox. I am influencer,content writer,author and publisher. Feel free to ask me any question and suggestions.