Quality code with code review tools
Automated code review is an effective way to identify code defects consistently, through predefined rules. Much of the code review process can be automated with static code analysis, which examines the source code without executing the program. Common types of static code analysers include linters, code smell detectors and security scanners. Here’s a list of Ruby on Rails essential libraries to simplify the code review process.
Linter
Linters help in detecting stylistic issues, syntax errors and poor coding practices. Most of the linters come with an auto fix for the basic mistakes.
Code Smell Detector
“a code smell is a surface indication that usually corresponds to a deeper problem in the system” — Martin Fowler
Duplicated code across multiple files is a code smell that can be recognised by most code smell detectors. Use it to refactor your code when necessary to increase code maintainability.
Security Scanner
Brakeman is helpful in detecting common security vulnerabilities such as command injections, cross-site request forgery and session manipulations. The solutions to correct them can be found on their website.
Application Performance
The Bullet gem helps to increase application performance by alerting against ‘N+1 queries’, unused eager loading and missing counter cache. In short, ‘N+1 queries’ is an anti-pattern that makes N+1 database calls but should be simplified to only 2 database calls. Eager loading is a query for an entity, that also loads related entities. A counter cache is used to cache the number of entries in a database table.
Code Coverage
Code coverage analysis tools compute the statement, branch, and function coverage. Most code coverage tools generate reports to indicate the lines of code that are covered by your tests and other basic statistics.
Continuous Integration Tools
Continuous integration tools enable automated building and testing to detect problems immediately. If you practice feature branching development, you will be using pull request builders instead. The basic configuration includes enforcing passing tests, linter rules, and code coverage thresholds.
Finally, code review!
With all these tools in place, what’s left is to identify the rules that are not covered and consolidate them in a checklist. There are ways to bypass the static code analysers’ rules, a senior developer should check the code before merging the pull request into the development branch.
Did I miss out anything? Let me know in the comments and I’ll add it in! Thanks!
