For a lot of companies, code reviews are rightly an important part of their processes. Whilst a lot of companies aren’t writing critical software resulting in life or death, shipping good and high-quality software should be at the top of everybody’s lists.
When performing a code review, at least one of these will be on your list of things to review:
- Implementation details
- Test coverage
- Following good design patterns
- Is the developer duplicating code that is already used elsewhere?
- Is the code reliable and maintainable?
Of course, there a lot of other items that we should be checking as part of a code review, however if your code reviews consist of manually checking coding standards, then you’re wasting your valuable time.
Recently on HackerNews there was a post from the Workiva tech blog which, I for one hope to be satire. A jab at the kind of cultures we’re all too familiar with. Regardless of whether it is or not, I’d like to quote it.
I know the Bender gif was obnoxious, but in my defense I thought you were joking when you started debating our code review prerequisite-checking robot on code style.
\— Workiva, We are ruthless on code reviews
Coding standards can — but more importantly — should be outsourced to a CI service such as StyleCI. That said, there are still a lot of popular CI services out there which still get in between the reviewer and the developer.
Why add more cognitive load onto a developer by commenting on every single instance where coding standards have not been maintained? They should be fixed automatically allowing both parties to continue focusing on implementation.
I do believe that in some instances commit-level comments may be useful, especially to a new developer who may be unfamiliar with coding standards, they’ll understand what parts of your standard they’ve not met. But why should they have to worry about this? Why should they spend time writing code that meets your standards when they could spend that time focusing on writing good, solid code that can be automatically fixed anyway?
Regardless, the way in which you conduct your code reviews is of course down to you. But keep in mind that your processes add more on to your developers and it can be avoided.