Code Review in C#: What to Check to Keep Your Code Healthy

Code Review in C#: Not Just a Checkbox, but a Production Saver

Have you ever seen code that works but makes you want to close your eyes? "Magic numbers", loops within loops, async void and null where it shouldn't be. Code review in C# is not a bureaucratic procedure, but the last line of defense before a bug goes into production. Or, even worse, before your colleagues have to maintain the code, cursing the author.

In this article, we'll break down what you should really pay attention to when reviewing C# code. No fluff — only specific cases, antipatterns, and examples. If you're a junior — this is your checklist. If you're a senior — refresh your memory. Let's go.

1. Null — The Main Enemy of a C# Developer

The infamous NullReferenceException is the cause of millions of sleepless nights. The first thing we check during a code review: protection against null.

What should raise a red flag?

\n
• Lack of a null check before accessing properties.
\n
• Returning null from methods where a collection is expected.
\n
• Ignoring nullable contexts (#nullable enable).
\n

Bad:

public string GetUserName(User user)\n{\n    return user.Name.ToUpper(); // user could be null!\n}

Good (C# 8+):

public string GetUserName(User? user)\n{\n    return user?.Name?.ToUpper() ?? "Unknown";\n}

Code review tip: require enabling Nullable in new projects. It's not just trendy, it saves you from silly mistakes. C# code review without checking nullable is like driving without a seatbelt.

2. Asynchrony: async/await Without Pitfalls

Asynchronous programming in C# is a powerful tool, but when used incorrectly, it turns into a time bomb. During a review, we check for three main sins.

Sin #1: async void

async void methods cannot be tracked — an exception will fall into the final thread and kill the process. Only acceptable for event handlers (e.g., a button in WinForms).

Bad:

public async void LoadDataAsync()\n{\n    var data = await _service.GetDataAsync(); // An error will kill the process\n}

Good:

public async Task LoadDataAsync()\n{\n    var data = await _service.GetDataAsync();\n}

Sin #2: Blocking Asynchronous Code

.Result or .Wait() in an asynchronous context is a sure path to a deadlock.

Bad:

var result = _service.GetDataAsync().Result; // deadlock in UI applications

Good:

var result = await _service.GetDataAsync();

Sin #3: Missing CancellationToken

Long-running operations should be cancellable. If the method signature doesn't have a CancellationToken, ask the author: "What happens if the user closes the tab?"

3. LINQ: Beauty or Slow Death?

LINQ is elegant. But code review often reveals that behind the elegance lies O(n²) or multiple passes over a collection.

Typical mistakes when reviewing C# code with LINQ:

\n
• Multiple enumeration: .Count() > 0 + .First() — two passes. Use .Any() and .FirstOrDefault().
\n
• Forgotten ToList(): lazy loading can cause a database query to execute after the DataReader context is already closed.
\n
• Where + Select = redundancy: if you can use a single SelectMany, use it.
\n

An example that should raise a red flag:

var result = l