Code-Review: 7 common mistakes
Code-Reviews can make a big difference in the quality of your code. But there's a catch: They have to be done right to really reap the benefits. Here are the most common mistakes people make when doing code reviews.
1. A LOT OF FOCUS ON STYLE AND SYNTAX
These types of "reviews" are common: they're usually just about the superficial writing style. Although cleanliness is important, if there are more pressing issues, this mistake is often made because these types of errors are easy to spot. Every developer's eyes are accustomed to spotting things like extra spaces, unnecessary lines of code, etc., and we automatically correct them.
This is how it goes;
By automating things, a machine can do it even better. It's best to set up a style guide and use certain tools to automatically improve code. All developers in the company should use it, regardless of whether they work with Emacs, VIM, Visual Studio or IntelliJ. Static code analysis tools can detect many irregularities and are better than any human. The definition of the style guide and code analysis should be a prerequisite for a good review.
A review should focus on simplifying syntax that can't be caught by automatic tools. It's easy to get caught up in small details and typos. But the main goal is to understand and improve the bigger picture.
2. SKIPPED TESTS
Many people see tests in reviews, but they only glance at them and then move on to implementation. Tests in reviews are boring. Always setting up, asserting, tearing down – and repeating. With so many repetitions, people are often not as attentive: „It will work out somehow."
This is how it goes;
Remember, tests are code too and deserve a proper review. This is also a great opportunity to check if your code is actually being tested properly. Things like this require a lot of concentration and understanding for every change - so it's not easy. Everyone involved should also pay attention to this, because if not everyone is on the same page, it will be an uphill battle. It should be clearly defined what is to be tested, how it is to be done and what is crucial for the operation of the app, etc. Ideally, then everyone also enters into a pact for adherence to the rules ;-)
3. ONLY REVIEW THE NEW THINGS
Most people pay more attention to new, green lines of code than they do to deleted, red ones, right? Yeah, usually adding code is more important, but an old line that gets deleted by accident can be a real troublemaker if you don't have a well-tested system.
This is how it goes;
While all changes are made, the previous, deleted lines are displayed. In this way, you can compare old and new lines and find out what differences there are, unless they are already obvious. But you can also take a step further: For example, if a method is removed, the code review is the right time to find out whether all calls have been deleted accordingly. On the other hand, it is worth checking whether a deleted call was the last use of a specific method in the code. Maybe you can delete the unnecessary method right away.
4. BAD TIMING
A half hour before the demo is not a particularly good time for a code review. It often looks like this: Together with a request for review, you receive a message: "You just have to make sure everything is okay. We're deploying a demo in 15 minutes. Perfect
If you want to do a proper review, you need to take your time. You can't guarantee the quality of the code if you're under a lot of stress, and that's often because of bad management. Programmers feel like they're not responsible for this kind of thing, but it doesn't matter who's to blame. The point is that when everyone's rushing around, some incorrect code sneaks in, and it might even go unnoticed.
