Skip to content

Guia de Padronização de Código C# para Equipes ​

1. Convenções de Nomenclatura ​

TipoExemploConvenção
ClassePessoaFisicaPascalCase
InterfaceIPessoaServicePascalCase com prefixo I
MétodoObterPessoaPorId()PascalCase
Parâmetro de métodostring nomePessoacamelCase, sem underscore
Variável localvar quantidadecamelCase
Campo privado_quantidadeTotalcamelCase com prefixo _
Campo protegidoquantidadeTotalcamelCase, sem _
ConstanteMAX_TENTATIVASUPPER_SNAKE_CASE
EnumTipoDocumento.CPFPascalCase
NamespaceEmpresa.Projeto.ModuloPascalCase

2. Organização do Código ​

  1. Ordem sugerida dentro da classe:

    • Campos privados
    • Constantes
    • Propriedades públicas
    • Construtores
    • Métodos públicos
    • Métodos privados
  2. Espaçamento:

    • Uma linha em branco entre membros da classe
    • Não usar múltiplas linhas em branco consecutivas

3. Propriedades ​

  • Usar propriedades automáticas:
csharp
public string Nome { get; set; }
  • Com lógica adicional:
csharp
private string _nome;

public string Nome
{
    get => _nome;
    set => _nome = value.Trim();
}

4. Comentários e Documentação ​

  • Comentários XML para membros públicos:
csharp
/// <summary>
/// Obtém uma pessoa pelo ID.
/// </summary>
/// <param name="id">Identificador da pessoa</param>
/// <returns>Instância da pessoa</returns>
public Pessoa ObterPessoaPorId(int id) { ... }
  • Evitar comentários redundantes.

5. Uso de var ​

  • Usar var quando o tipo for óbvio:
csharp
var pessoa = new Pessoa(); // OK
int idade = 30; // Tipo explícito preferido aqui

6. Tratamento de Exceções ​

csharp
try
{
    // código
}
catch (FileNotFoundException ex)
{
    // tratamento específico
}
catch (Exception ex)
{
    // tratamento genérico
    throw;
}

7. Estrutura de Pastas e Namespaces ​

  • Organize por responsabilidade: Controllers, Services, Repositories, DTOs, Entities.
  • Namespaces devem refletir a estrutura.

8. LINQ e Lambdas ​

csharp
var ativos = pessoas.Where(p => p.Ativo).ToList();

Evite lógicas muito aninhadas.


9. Métodos Assíncronos ​

  • Nome com sufixo Async: ObterDadosAsync
  • Evitar .Result ou .Wait()
  • Usar await corretamente

10. Outros Pontos ​

  • Evite números mágicos: use constantes nomeadas
  • Use readonly para campos imutáveis
  • Aplique SOLID e Clean Code
  • Nome de arquivo deve ser igual à classe

11. Princípios SOLID (Resumo Prático) ​

PrincípioDescriçãoDica prática
SRPUma classe deve ter uma única razão para mudar.Separe responsabilidades.
OCPAberta para extensão, fechada para modificação.Use herança/composição.
LSPSubtipos devem poder substituir seus tipos base.Heranças seguras.
ISPMúltiplas interfaces específicas.Evite interfaces gigantes.
DIPDependa de abstrações.Use injeção de dependência.

12. Boas Práticas de Clean Code ​

PráticaExplicaçãoExemplo
Nomes significativosUse nomes claros que expressem intençãovar clienteAtivo = clientes.Where(c => c.Ativo);
Evite comentários inúteisCódigo claro evita explicações redundantesRuim: // Soma dois números
return a + b;
Métodos curtosMelhor manutenção e leituraPrefira: CalcularTotalPedido() com 10 linhas
Evite duplicaçãoReutilize lógica comumExtraia ValidarEmail(string email) para uso geral
Uma responsabilidadeUm método = uma tarefaSeparar SalvarUsuario e EnviarEmailBoasVindas()
Valide argumentosEvita exceções inesperadasif (nome == null) throw new ArgumentNullException(nameof(nome));
Composição > HerançaFacilita manutençãoUse EmailService dentro de UsuarioService, em vez de herança
TestabilidadeCódigo testável é desacopladoMétodos com dependências via interfaces, não concretas
Evite efeitos colateraisMétodos devem ser previsíveisEvite que AtualizarSaldo() altere também o status do usuário