The Subtle Art of Code Reviews 🌱

Some code review best practices 🌱

This is a great article I came across while researching for the code review best practices. It beautifully elaborates on how design, functionality, complexity, testing, naming, commenting, style, consistency, documentation, and context are all important components of a code review.

Time. Attention. Communication ⏳‼️

A good review takes time and attention. It requires us to think critically about the programming logic. For beginners, it can feel overwhelming to stare at the code someone else wrote to suggest something meaningful. There is a fear of being wrong. A fear of offending the person writing the code. I know, because I felt all those. However, in open-source development, it is always important to remain polite and respectful in communication while giving constructive feedback. We can sometimes disagree with the review but if we do so, we should communicate that politely.

It is also important to keep an open mind while giving and receiving feedback. It is through this exchange of ideas, and feedback that we can improve over time.

If you have some coding experience and spend enough time and give undivided attention to the code, it is almost always possible to come up with suggestions for improvement.

Start small 🐌 🌱

If you are a beginner, start small and learn from others. I learned a lot of important things by reading professor Dave's reviews. Then I realized that it is by seeing how more experienced people review code, that I can get better. I made some notes of the things I learned by reading a lot of his code reviews on GitHub. I turned those things into some sort of a checklist:

• Ask specific questions regarding certain lines of code, if unclear.
• Look for unused dependencies and ways to optimize package.json.
• Look at the code from the context of the entire codebase.
• Leave some words of encouragement to point out what the developer is doing right!
• Focus on functionality and compatibility.
• Look for clear names and proper naming conventions.
• When reviewing README or CONTRIBUTING.md files, look for consistency in style, formatting, spelling, and grammar.
• Make sure that the design and UI look good.
• Ensure that the unit tests are appropriately designed for the code.
• Make sure that the code conforms to a certain style guide provided.

In linters we trust 🚀

Automated code checkers and static tool analyzers can help a reviewer save a lot of time looking for silly typos or stylistic errors. Linters and scanners act like spell and grammar checks for a code. With the headache of formatting and other stylistic issues out of the way, the reviewer can focus on the actual logic of the code. As code reviewers, it is essential to make use of the automated code checkers available to save time and sanity.

Closing thoughts on productivity 💭

If you are someone like me who loves reading about psychology and productivity, this is a great article!