Being Your Own Rubocop
Refactoring one’s code can often be a tedious and frustrating process. One of our key responsibilities as programmers is to make our code as readable and concise as possible. Getting your code to function the way you want it to simply isn’t enough. Rubocop, a Ruby static code analyzer and formatter, serves as a guide to ensure that your code is free of errors and follows a series of syntactical conventions abided by Rubyists. It’s an extremely useful tool for refactoring as it lists the various issues with your code and where they’re located. This makes the process of refactoring a more efficient and sequential experience.
While Rubocop is undoubtedly helpful, it’s important to maintain a fair bit of skepticism when it comes to its list of violations. We need to use our better judgement when it comes to refactoring or else we end up making adjustments that are unnecessary or even detrimental. I realized this while working on a coding exercise at Launch School. I was required to program a rudimentary tic-tac-toe game. One of the simplest aspects of this program was displaying the board through the use of hyphens, vertical bars, plus signs, and the interpolated elements of an array. The end result is shown in the picture below:
Two kinds of Rubocop violations arise when running my configuration file:
- Method has too many lines.
- Assignment Branch Condition size is too high.
The first violation may be self-explanatory to those with programming experience. The method exceeds the designated number of lines specified within my Rubocop file. (In this case, the limit is 10 lines). The second violation is a little more ambiguous. It’s contingent upon the following equation: √(A² + B² + C² ). (Assignment Branch Condition) ‘Assignment’ represents the amount of variable assignments, ‘Branch’ represents the amount of method calls, and ‘Condition’ represents the amount of conditional statements (e.g., if/else statements). In this case, the repeated implementation of the ‘puts’ method prompts this particular violation.
It’s important to bear in mind that the reason these violations exist is to assist Rubyists in maintaining a degree of clarity and readability within their code. However, we can’t always take all of Rubocop’s suggestions at face value. Although the ‘display_board’ method prompts these two violations, its purpose and configuration is pretty obvious. The board is even outlined within the code itself! Building an alternative framework to this method in order to bypass the aforementioned solution isn’t necessary. In fact, it can even make your solution more elaborate and confusing to your average Rubyist, which defeats the purpose of using Rubocop in the first place! I learned this the hard way. In an attempt to rid my code of any violations, I coded the following solution:
While all this code effectively silenced Rubocop, it didn’t accomplish much. In fact, it only made matters worse! I spent hours toiling away at my ruby file in order to build this solution. And while the specific configuration file within my directory might approve of this, the end certainly doesn’t justify the means. I had to build four separate methods in order to get this to function properly! The aim should be to reduce complexity, not to increase it. Let’s view these solutions side by side and compare the two:
I’m confident that even someone with zero programming experience has a better chance of dissecting the solution on the left than the one on the right. Many are familiar with what a tic-tac-toe board looks like. And that should be the aim of refactoring one’s code; increasing accessibility. Even Rubocop itself knows it’s not perfect, which is why it provides users a means of disabling/enabling certain cops.
While Rubocop remains a helpful tool for refactoring, it’s important to exercise caution when considering its suggestions. Use it as a guide to make your code more intelligible, but use your deductive reasoning skills to make meaningful adjustments and avoid nitpicking. Otherwise, you might end up like me: 3+ hours deep into a solution that bears trivial, laborious complexity with a self-imposed headache. Moral of the story; be your own Rubocop.
