Gotta Catch' Em All
Code reviews are a common practice nowadays when more than two developers are working on the same repository. A review process helps to catch any issues with logic and code design before they reach production. To eliminate major error-prone parts of our code, we should adopt TDD in our workflow.
Unfortunately, even the best tests won't identify code smells and code style issues. Some may say that those do not matter much since our code works, right?
They do matter as a code is read many more times than it is written. Good coding style eases reviews and good code design is easier to extend.
Probably no one writes perfect code at first attempt (and if you do, we probably want to work with you). Luckily there is a bunch of tools which help you detect those small and annoying issues early in the process.
Catch them even before committing
Git hooks allow you to setup custom actions to be executed right before committing your changes. When a git hook fails the commit operation will be aborted. The goal is to setup such hooks, which will help us identify issues with our code. Instead of setting up each git hook manually we can use Overcommit Ruby gem. Once installed we can define our checks in
.overcommit.yml file e.g.
PreCommit: RuboCop: enabled: true problem_on_unmodified_line: warn on_warn: pass # Treat all warnings as failures Reek: enabled: true
Such setup will execute Rubocop only on lines modified by us and ignore any
other issues in the modified file. Ignoring those is useful when we work with legacy, ugly code, where each small change would generate a huge amount of warnings. Best is to handle them one by one so we won't overwhelm our feature commit by introducing changes only to make Rubocop happy. Also on each
commit, we will execute Reek to find typical and most popular code smells.
Catch them before merging
If for some reason you do not want to setup such precautions on your local dev environment there are also tools which can be used on your CI server, one of them is Pronto (by the way, it can also be used locally).
When properly integrated with your CI server it will perform initial "code review" of your GitHub Pull Request, so you can see immediately, after the build finishes, if there are any issues with your code.
Such CI setup is especially useful when you need to enforce linters and code smell checkers on new team members/freelancers who do not want (or do not know how) to install such tools locally.