C# en equipo: code style y convenciones que salvarán tu proyecto

Por qué el code style no es cuestión de «a mí me gusta así»

¿Alguna vez has abierto código ajeno en C# y te has sentido como un arqueólogo excavando las ruinas de un templo antiguo? public int a;, var x = GetSmth() sin contexto y métodos de 400 líneas. Si es así, sabes cómo duele la cabeza de un equipo sin un code style unificado.

Trabajar en equipo no es solo cuestión de Git y code review. Se trata de que otras personas lean tu código. Y si escribes para ti mismo, el code style para C# es una burocracia aburrida. Pero si escribes para el equipo, es un salvavidas para los nervios, el tiempo y la producción.

En este artículo analizaremos qué convenciones de C# funcionan realmente en 2024, cómo implementarlas sin dolor y por qué EditorConfig es tu mejor amigo. ¡Allá vamos!

Reglas básicas: sobre qué acordar primero

1. Nomenclatura (naming conventions)

En C# existen estándares estrictos, pero los equipos a menudo los infringen. Aquí tienes el mínimo de oro que acepta el 90% de los equipos .NET:

\n
• PascalCase — para clases, métodos, propiedades, campos públicos: public class UserService, public string GetUserName().
\n
• camelCase — para variables locales, parámetros de métodos, campos privados (a menudo con el prefijo _): private int _userId;, var userName = "Alex";.
\n
• Evita la notación húngara — strName, intCount son cosa del pasado. El tipo de la variable debe ser obvio por el contexto.
\n
• No abuses de las abreviaturas — GetUsrInf() es peor que GetUserInformation(). Excepción: abreviaturas ampliamente aceptadas (IO, UI, DTO).
\n

// Mal\npublic class user_service\n{\n    public int id;\n    public string nm;\n    private string _data;\n    public string GetData() => _data;\n}\n\n// Bien\npublic class UserService\n{\n    public int Id { get; }\n    public string Name { get; }\n    private readonly string _userData;\n\n    public string GetUserData() => _userData;\n}

2. Formato: espacios, llaves, líneas en blanco

Los debates sobre si poner un espacio antes de los dos puntos en catch (Exception e) son interminables. Por eso, usa herramientas automáticas. Pero aún así se necesitan acuerdos básicos:

\n
• Sangría: 4 espacios (la tabulación se usa poco en C#, pero si el equipo elige tabs, está bien).
\n
• Llaves: siempre en una nueva línea (estilo Allman). Es el estándar para C#.
\n
• Una línea en blanco entre métodos. Dos entre clases.
\n

// Mal (llaves en la misma línea es cosa de Java, no de C#)\npublic void Process() {\n    var result = Calculate();\n    return result;\n}\n\n// Bien (estilo Allman)\npublic void Process()\n{\n    var result = Calculate();\n    return result;\n}

Convenciones avanzadas: dónde se tropieza más a menudo

3. Uso de var

Uno de los debates eternos. La regla es simple: usa var cuando el tipo sea obvio por el lado derecho. Si no, escríbelo explícitamente.

// Se puede usar var\nvar users = GetUsers(); // el tipo es obvio\nvar dictionary = new Dictionary<string, int>(); // declaración larga\n\n// Mejor explícito\nUser user = GetUserById(id); // no es obvio que devuelve un User\nDictionary<string, int> result = ParseData(); // tampoco es obvio

Si a tu equipo no le gusta var, simplemente acuérdalo. Lo importante es la uniformidad.

4. Trabajo con LINQ

LINQ es una herramienta poderosa pero traicionera. Un error común son cadenas de 10 métodos que parecen un conjuro. Acuerda:

\n
• Divide las expresiones LINQ largas en varias líneas.
\n
• No abuses de .Select() donde se necesita un pr