Скачать или смотреть How To Review Code

Hey, how’s it going? Today, I want to talk about code reviews, riffing on some pretty good advice from Matthias Endler, who is well-known in the Rust community. He wrote about how to review code, and I think he nailed some key points.

These days, most of us spend more time reading code than writing it, especially with AI tools like Claude and OpenAI cranking out code for us. That means reviewing and understanding code matters more than ever. Writing code is usually the fun part, while reading and reviewing tends to feel tedious, but those tasks are just as critical now.

According to Matthias, he spends up to 70 percent of his time reviewing, which makes sense if most new code comes from somewhere else. Over time, he noticed that inexperienced reviewers focus too much on style, like nitpicking about semicolons or spacing, instead of checking if the code is maintainable and works within the bigger system. A solid review considers whether changes solve the real problem, what future issues might come up, and how everything fits in the larger structure.

It also matters to look at the parts of the code that were not changed, since missing an update to related sections or docs can create bugs and confusion. A useful technique is to read around the changed lines to catch those problems. Matthias has a cheat sheet with good questions: How does the code fit into the rest of the system?

What other parts does it touch? Does it change the structure? Could it affect future work?

These questions push you to look at the big picture, not just tiny tweaks. Naming is a huge deal, good names help everyone understand what is going on, bad names make things confusing. He gives an example where changing “user” to “username” and “l” to “level” made the code way clearer.

It is okay to say no to bad changes, but you have to explain why and suggest better alternatives. You are not rejecting a person, just the code, and it is about keeping the project healthy. If you always argue about the same stuff, make a style guide.

Remember, reviews are about teamwork and helping each other get better, not just finding mistakes. Positive feedback matters too, if you see something cool, say so. When pointing out problems, focus on explaining why, not just how.

Give clear reasons and, if possible, links to more info. For example, instead of saying “Do not do this,” you could say “This will fail if users is empty, use this safer pattern instead.” It is all about being clear, helpful, and supportive.