Welcome to the twenty-first edition of The Catch Block!
In this edition: tips for blind code reviews. Plus awesome APIs, code coverage, console apps, maintaining vs. building, and translating design into code.
Tips for Doing Blind Code Reviews
I've been having to do something quite a lot lately that isn't my favorite thing to do: blind code reviews.
A "blind" code review happens when you are asked to review code for an application, system, or website that you are not already familiar with. I've been doing a lot of these lately, primarily because of all the projects my team is responsible for.
Let's be honest; these kinds of reviews are often a waste of time. A good reviewer understands the context around the code they are reviewing, and in these situations that context is missing; the reviewer hasn't had the experience necessary to gather it. Therefore the reviewer often ends up "rubber-stamping" the code; passing on changes that they don't understand on the basis that since the original developer wrote it this way, it must be correct. This is dangerous, since it makes it more likely that an unintended code change will make its way to production.
We as reviewers can combat this. I've collected four tips that help me do better blind code reviews. Following these tips will not make up for the lost context, and you still might need to spend the time to gather it, but these tips will make it so you no longer have to just "rubber-stamp" the code.
Read Every Line, Even If You Don't Understand It
Yes, seriously. The best way to get familiar with a given codebase is to read it, even if you don't understand it yet. Read every change, and more importantly read enough context around the changes to give you an idea of what each change is doing.
If you're being asked to code review something you are not familiar with, it's probably because whoever is in charge of making that decision (manager, etc.) wants you to become familiar. Take the extra time and learn some of the context around why the original developer made the decisions they did.
Check for Syntax, Formatting, & Grammar
The first thing you can do is check for basics, like syntax, formatting, and grammar. These things matter when reading code, and one of the points of doing code reviews is to make the code easier to read and understand for future developers (which just might be you).
Check for team standards, like camelCase vs. PascalCase for naming, spaces vs. tabs, whether or not braces need to be on their own lines, etc. Whatever the standard is for these things in your project, make sure you keep to that standard.
Comments are King
Every single code change that gets committed to the code base, unless it is immediately and incredibly obvious to any developer what it is doing, needs some kind of comment to explain what changed. You, as the reviewer, have the responsibility to ensure that these comments exist.
You also have the responsibility to ensure that said comments are easy to read and clearly express their ideas in whatever primary spoken language your team uses. No one wants to come back to a complicated code base only to find that the comments are nigh unreadable.
Chat With the Original Developer
IMO this is the single most important thing you can do when reviewing code you are not familiar with. Find the original developer and ask them questions about the code they wrote.
Ask them why they wrote it as part of a particular class, or in a particular location. Ask about the security of the code; is it known to be vulnerable, and to what? Ask about the reasoning behind why they structured the code in a certain way, or why they chose a given architecture rather than another. You will learn something that most likely wasn't obvious from reading the code when doing this.
Blind code reviews aren't fun, but they are a necessary part of any lead developer's job. Following these tips will help ensure they aren't a waste of time, and might even provide useful insight as to why the code was written in this way, and what we can do to improve it in the future.
Quality Reads
- Announcing the new TypeScript Website (Orta Therox) - Said new TypeScript website is typescriptlang.org.
- How to Set Code Coverage Goals and Interpret Results (Dennis Dietrich)
- Binding parameters from the query string in a Blazor component (Gérald Barré)
- .NET Core Console Apps - A Better Way? (Shawn Wildermuth)
- Is Maintaining Easier than Building? (Jonathan Danylko)
- Build Awesome APIs with Entity Framework Core (Nickolas Fisher)
- Handle HTTP Status Codes With Razor Pages (Khalid Abuhakmeh)
- Translating Design into Code: Why is it so Hard? And How Can You Optimize it? (Nada Rifki)
- Best way to create an empty collection (array and list) in C# (.NET) (Jiří Činčura)
A Quick Announcement
The Catch Block will take the next week off, to prepare for some changes coming to the blog (and to help get my kids settled into remote schooling). We'll be back on 19th August with bigger and better stories, links, and tips.
Catch Up with the Previous Issue!
Matthew Jones
Thanks for reading (assuming you aren't actually blind, in which case, thanks for listening), and we'll see you next week!
