C# em equipe: code style e convenções que salvarão seu projeto

Por que code style não é sobre "eu acho assim"

Você já abriu o código de outra pessoa em C# e se sentiu um arqueólogo escavando ruínas de um templo antigo? public int a;, var x = GetSmth() sem contexto e métodos com 400 linhas de comprimento. Se sim, você sabe como dói a cabeça de uma equipe sem um code style unificado.

Trabalhar em equipe não é só sobre Git e code review. É sobre o fato de que outras pessoas leem seu código. E se você escreve para si mesmo, code style para C# é uma burocracia chata. Mas se você escreve para a equipe, é uma salvação para os nervos, o tempo e a produção.

Neste artigo, vamos analisar quais convenções C# realmente funcionam em 2024, como implementá-las sem dor e por que o EditorConfig é seu melhor amigo. Vamos lá.

Regras básicas: sobre o que entrar em acordo primeiro

1. Nomeação (naming conventions)

Em C#, existem padrões rígidos, mas as equipes frequentemente os violam. Aqui está o mínimo de ouro que 90% das equipes .NET aceitam:

\n
• PascalCase — para classes, métodos, propriedades, campos públicos: public class UserService, public string GetUserName().
\n
• camelCase — para variáveis locais, parâmetros de métodos, campos privados (geralmente com prefixo _): private int _userId;, var userName = "Alex";.
\n
• Evite a notação húngara — strName, intCount — isso é coisa do passado. O tipo da variável deve ser óbvio pelo contexto.
\n
• Não abreveie sem necessidade — GetUsrInf() é pior que GetUserInformation(). Exceção: abreviações amplamente aceitas (IO, UI, DTO).
\n

// Ruim\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// Bom\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. Formatação: espaços, chaves, linhas em branco

As discussões sobre se deve colocar um espaço antes dos dois pontos em catch (Exception e) são intermináveis. Portanto, use ferramentas automáticas. Mas acordos básicos ainda são necessários:

\n
• Indentação — 4 espaços (tabulação em C# é raramente usada, mas se a equipe escolheu tabs, tudo bem).
\n
• Chaves — sempre em uma nova linha (estilo Allman). Este é o padrão para C#.
\n
• Uma linha em branco entre métodos. Duas — entre classes.
\n

// Ruim (chaves na mesma linha — isso é Java, não C#)\npublic void Process() {\n    var result = Calculate();\n    return result;\n}\n\n// Bom (estilo Allman)\npublic void Process()\n{\n    var result = Calculate();\n    return result;\n}

Convenções avançadas: onde as pessoas mais tropeçam

3. Uso de var

Uma das discussões eternas. A regra é simples: use var quando o tipo for óbvio pelo lado direito. Se não for, escreva explicitamente.

// Pode usar var\nvar users = GetUsers(); // tipo óbvio\nvar dictionary = new Dictionary<string, int>(); // declaração longa\n\n// Melhor explícito\nUser user = GetUserById(id); // não é óbvio que retorna User\nDictionary<string, int> result = ParseData(); // também não é óbvio

Se sua equipe não gosta de var — apenas entrem em acordo. O importante é a consistência.

4. Trabalhando com LINQ

LINQ é uma ferramenta poderosa, mas traiçoeira. Um erro comum são cadeias de 10 métodos que parecem um feitiço. Combinem:

\n
• Divida expressões LINQ longas em várias linhas.
\n
• Não abuse de .Select() onde um pr