Rubocop is a code-style linter for Ruby based on the official . Rubocop supports autocorrection & is flexible in terms of the configuration of various cops based on our preference. Ruby style guide In this blog post, we discuss the various steps on how we can improve code quality using Rubocop in our codebase. Why do we need Rubocop? : There are various patterns in which developers write code. To harmonize the coding style, we can use Rubocop. By enabling and disabling rules with Rubocop, we can discuss with the team what good practices we need to follow. Creating a Standard : Sometimes, when a PR is sent for review, the reviewer might spend time commenting on the code style/format, such as extra whitespaces and missing lines at the end. By integrating Rubocop into pre-commit hooks and GitHub Actions, the developer can be made aware of offenses even before the PR is reviewed. Ease the process of understanding & reviewing code As Ruby beginners, we may not be aware of the practices used by the Ruby community. In the form of various gems, Rubocop provides us with an excellent starting point for understanding all of them. Best Practices: Rubocop Config In order to integrate Rubocop into our codebase, add the following gems to your Gemfile gem 'rubocop', '1.23.0', require: false gem 'rubocop-performance', '~> 1.12.0', require: false gem 'rubocop-rails', '~> 2.12.0', require: false gem 'rubocop-rake', '~> 0.6.0', require: false gem 'rubocop-rspec', '~> 2.6.0', require: false : . rubocop-performance Performance optimization analysis : . rubocop-rails Rails best practices & coding convention : Rspec (used for Ruby code testing) specific code analysis. rubocop-rspec The next step is to create the which contains the cops to be enabled/disabled, and the files that we don't want to run specific cops on. .rubocop.yml An example can look like this require: - rubocop-performance - rubocop-rake - rubocop-rails - rubocop-rspec AllCops: DisabledByDefault: false NewCops: enable TargetRubyVersion: 2.6.3 Exclude: - db/schema.rb - node_modules/**/* - vendor/**/* Layout/FirstArgumentIndentation: Exclude: - spec/controllers/api/payments_controller_spec.rb what this piece of code does is, excludes all files under AllCops::Exclude when running Rubocop. disables running of Cop on the files under Exclude. Layout/FirstArgumentIndentation Rubocop TODO Approach For existing projects, RuboCop provides a file that records all the offenses from our codebase. Rather than having to fix everything at once, we can fix each offense as we touch the corresponding piece of code. .rubocop_todo.yml In order to generate the todo file use the command which runs rubocop on your entire codebase and adds the offenses in the code as disabled. rubocop --auto-gen-config --exclude-limit 10000 is a hack to make sure that Rubocop will not disable any cops in the . --exclude-limit 10000 .rubocop_todo.yml file An example of how the will look like .rubocop_todo.yml # This configuration was generated by # `rubocop --auto-gen-config --exclude-limit 10000` # on 2022-09-24 07:33:55 UTC using RuboCop version 1.23.0. # The point is for the user to remove these configuration records # one by one as the offenses are removed from the code base. # Note that changes in the inspected code, or installation of new # versions of RuboCop, may require this file to be generated again. # Offense count: 8 # Cop supports --auto-correct. # Configuration parameters: IndentationWidth. Layout/AssignmentIndentation: Exclude: - 'app/controllers/home_controller.rb' - 'app/helpers/application_helper.rb' - 'app/helpers/regex_helper.rb' The next step is to let know to ignore the files in . You can do this by inheriting the file in the main config. rubocop .rubocop_todo.yml inherit_from: .rubocop_todo.yml inherit_mode: merge: - Exclude require: - rubocop-performance - rubocop-rake - rubocop-rails - rubocop-rspec ... This is how your will look after configuring the todo file. Then when we run rubocop, it pulls the configuration from , which then pulls the configuration from , which contains all the excluded files. Therefore, we won't see any offenses. .rubocop.yml .rubocop.yml .rubocop_todo.yml An added todo file does not mean that the offenses have been solved, it simply indicates that we have suppressed the warnings we were receiving repeatedly. As a result, the offenses remain present and now it is our responsibility to rectify each one individually. The approach that we have been following at to solve these offenses includes the following steps: HackerRank Pick up a cop with offenses in the file. .rubocop-todo.yml Read the documentation at . docs.rubocop.org/rubocop/1.36/index.html Check if the Cop supports . Safe Autocorrection Check the default enforced style for the Cop. Check if the Style is shared across various languages. The reason for this is to bring consistency among our developers. If we change the enforced style, drop a note to the Engineering Team. Finally, create a PR. It is important to not overcompensate for old code with many violations but to ensure that the new code adheres to the standards enforced by Rubocop config and to incrementally improve it. Configuring Cops As I was cleaning up the file at HackerRank, we discovered that some cops needed configs different from what the official Ruby style guide recommends. Listed below are a few examples of those, along with the reason and how you can modify the defaults. .rubocop-todo.yml In Ruby, the last line in a method is something that is returned, so the official style guide recommends avoiding returns unless necessary. However, we disabled this Cop for the following reasons: Style/RedundantReturn: Almost all languages adhere to explicit returns, which makes transitioning between them easier for the developer. It simplifies the code at first glance and doesn't require any previous language-specific knowledge. When I first started with Ruby, I wasn't aware of this, so when my code stopped working, I assumed a return statement was missing. Eventually, I realized that it wasn't the return statement but something else. You can disable this cop using the following piece of code in .rubocop.yml Style/RedundantReturn: Enabled: false : For defining an array, the Style Guide recommends using the format for strings that don't have any spaces. In the case of spaces using the will be considered an offense. Style/WordArray % %w # bad STATES = ['draft', 'open', 'closed'] # good STATES = %w[draft open closed] # bad (contains spaces) STR = %w[foo\ bar baz\ quux] # good (contains spaces) STR = ['foo bar', 'baz quux'] → There is a problem with this format if the strings have spaces (which is highly likely in a large codebase), there will be two different formats used in code: "Brackets" for strings with spaces and "%" for strings without spaces. → Additionally, brackets are a common format across many languages, so if a newcomer is trying to understand your code, they won't have to learn all kinds of syntax first. We can bring consistency to our developers by using brackets. For the above two reasons, we configured the default to . You can use the following piece in . Brackets .rubocop.yml Style/WordArray: EnforcedStyle: brackets : The configuration for this is similar to . Style/SymbolArray Style/WordArray Style/SymbolArray: EnforcedStyle: brackets : The use of this cop to check if the length of a method exceeds some maximum value. The default is. 10 but you can take a look at your codebase and analyze the suitable number for it. Metrics/MethodLength It also provides a configuration like which is available for array, hash, and heredoc where each literal will be counted as one line regardless of its actual size & where we can provide the list of methods that we want the cop to ignore. CountAsOne IgnoredMethods The approach we have been following includes: Taking the number for which most methods have offenses. Set that as the Max limit. Add the remaining methods as offenses. Gradually decrease the limit. The goal was to avoid unnecessarily high lines of code in new methods and also not have to worry too much about refactoring old code. Metrics/MethodLength: Max: 100 CountAsOne: ['array', 'hash', 'heredoc'] IgnoredMethods: ['a','b'] These are some Cops which we have configured differently compared to the default Style Guide after discussing with the entire team. Maintaining the Standard Now that we have the configuration in place, we need to make sure that the new code written doesn't contain the offenses. To do this we can do the following: Make use of that run Rubocop across all the configured Cops. pre-commit hooks Setup that report offenses on the PR. You can also make these checks as required to pass for merging the code. Code Climate/Github Actions PS: The following screenshot is a trend on how we have improved the code quality at by cleaning up the file. HackerRank .rubocop_todo.yml I hope this article helps to configure Rubocop in your code bases & improve the code quality. Also Published Here
