Code Review en C#: qué revisar para que el código no duela

Code Review en C#: no solo un trámite, sino un salvavidas para producción

¿Alguna vez has visto código que funciona, pero del que quieres cerrar los ojos? «Números mágicos», bucles dentro de bucles, async void y null donde no debería estar. El code review en C# no es un procedimiento burocrático, sino la última línea de defensa antes de que un bug llegue a producción. O, peor aún, antes de que tus colegas tengan que mantener el código maldiciendo al autor.

En este artículo analizaremos en qué fijarse realmente al revisar código C#. Sin rodeos: solo casos concretos, antipatrones y ejemplos. Si eres junior, esta es tu lista de verificación. Si eres senior, refresca la memoria. ¡Allá vamos!

1. Null: el mayor enemigo del desarrollador C#

El famoso NullReferenceException es la causa de millones de noches sin dormir. Lo primero que revisamos en un code review: protección contra null.

¿Qué debería alertarte?

\n
• Falta de verificación de null antes de acceder a propiedades.
\n
• Devolver null desde métodos donde se espera una colección.
\n
• Ignorar contextos nullable (#nullable enable).
\n

Mal:

public string GetUserName(User user)\n{\n    return user.Name.ToUpper(); // ¡user puede ser null!\n}

Bien (C# 8+):

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

Consejo para code review: exige la activación de Nullable en proyectos nuevos. No solo está de moda, sino que evita errores tontos. Un code review C# sin verificar nullable es como conducir sin cinturón de seguridad.

2. Asincronía: async/await sin trampas

La programación asíncrona en C# es una herramienta poderosa, pero si se usa incorrectamente se convierte en una bomba de tiempo. En la revisión verificamos tres pecados capitales.

Pecado n.º 1: async void

Los métodos async void no se pueden rastrear: la excepción caerá en el hilo final y matará el proceso. Solo es aceptable para controladores de eventos (por ejemplo, botones en WinForms).

Mal:

public async void LoadDataAsync()\n{\n    var data = await _service.GetDataAsync(); // Un error matará el proceso\n}

Bien:

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

Pecado n.º 2: Bloquear código asíncrono

.Result o .Wait() en un contexto asíncrono es el camino directo al interbloqueo.

Mal:

var result = _service.GetDataAsync().Result; // interbloqueo en aplicaciones UI

Bien:

var result = await _service.GetDataAsync();

Pecado n.º 3: Ausencia de CancellationToken

Las operaciones largas deben ser cancelables. Si en la firma del método no hay CancellationToken, pregúntale al autor: «¿Qué pasará si el usuario cierra la pestaña?»

3. LINQ: ¿belleza o muerte lenta?

LINQ es elegante. Pero el code review a menudo revela que detrás de la elegancia se esconde un O(n²) o múltiples recorridos de la colección.

Errores típicos al revisar código C# con LINQ:

\n
• Recorrido múltiple: .Count() > 0 + .First() — dos recorridos. Usa .Any() y .FirstOrDefault().
\n
• ToList() olvidado: la carga diferida puede provocar que la consulta a la BD se ejecute después de que el contexto DataReader ya esté cerrado.
\n
• Where + Select = redundancia: si se puede usar un solo SelectMany, úsalo.
\n

Ejemplo que debería encender una alarma roja:

var result = l