Boas Práticas em Programação com C#

Neste artigo vou falar sobre algumas boas práticas em programação com C#, e justificando sua importância. Um código que não segue boas práticas vai sempre tender ao Big Ball Of Mud, dificultando muito sua compreensão, legibilidade e manutenção.

Existem inúmeras outras boas práticas, princípios e padrões recomendados. Como programadores, devemos sempre estudar mais e estender nosso atual conhecimento para nos mantermos relevantes perante o mercado e nossas equipes. Livros são uma excelente fonte de conhecimento, mas são geralmente negligenciados pelos profissionais na área. Nesse artigo eu listo 10 livros essenciais para Desenvolvedores .NET.

Padrão de Nomenclatura

Adotar e seguir um padrão de nomenclatura é essencial para a evolução de um projeto. Não fazer isso gera confusão tanto no desenvolvimento quanto na revisão do código, além da inconsistência na nomenclatura dar uma aparência de descuido ao código. Como revisar um código se a própria equipe não segue um padrão de nomes?

O padrão de nomenclatura utilizado para o C# define:

  • Classes e Métodos: PascalCase.
  • Parâmetros e variáveis: camelCase
  • Interfaces: devem iniciar com I, como IProductRepository.
  • Constantes: UPPER_CASE

Além disso, os nomes devem ser claros e legíveis. Evitar ao máximo utilizar abreviações que sejam ilegíveis, pois dificulta a leitura do código escrito. O tempo gasto para pensar no nome de variável vai ser compensado muitas vezes na leitura do mesmo código mais para frente.

Evitar uso excessivo de comentários

Primeiramente, peço atenção extra à palavra “excessivo”. Não acredito que os comentários devem ser abolidos de um código, já que em alguns cenários eles são úteis, como em descrição de algoritmos complexos.

Porém, o uso excessivo deles deixa o código sujo, adiciona “ruído” e pode mascarar código ilegível. Em muitos casos, se o comentário for removido, o código fica ilegível devido a má nomenclatura de variáveis e métodos, e de estruturação do algoritmos. Nestes casos, o correto não é escrever um textão nos comentários para explicar o que ele faz, e sim refatorar o bloco de código para obter maior legibilidade e clareza.

Outro cenário é o de comentários óbvios. Vou te dar um exemplo abaixo.

// Propriedade que representa a idade 
public int Age { get; }

Já vi a implementação de domínios inteiros contendo comentários em suas propriedades. Além do código ficar poluído, comentários desse tipo não contribuem para quem for manter. Deve-se considerar a ilegibilidade do nome da propriedade em relação ao conhecimento do domínio da equipe, já que existir a necessidade de adicionar comentários em muitas propriedades que tenham nomes usando jargão técnico do domínio indica que a própria equipe não está a par do domínio a ser implementado. Isso resulta em grandes chances de que os requisitos da aplicação vão estar desalinhados ao produto final desenvolvido.

Tamanho dos métodos

Não existe um tamanho universal recomendado para métodos. Porém, creio que conseguimos notar quando o tamanho de um método está saindo de controle, concorda comigo? Um tamanho que geralmente é utilizado como referência é o de 40 ou 50 linhas. Se está trabalhando em um método que tenha mais que esse tamanho, indico analisar e refatorar para utilizar métodos privados novos, para ir decompondo a lógica e deixando seu código mais legível.

Checagem de objetos nulos

Um dos erros mais comuns e causadores de bugs em produção é o NullReferenceException. Ele ocorre quando se tenta acessar uma propriedade ou invocar um método de um objeto nulo. E por que isso ocorre? Porque não fazemos uma verificação antes de realizar isso. Simples né? Mas exige uma disciplina grande durante o processo de desenvolvimento para identificar os pontos de risco de um NullReferenceException. A forma mais básica para se evitar isso é usar um if-else simples, além de entender que alguns métodos do LINQ como SingleOrDefault e FirstOrDefault podem retornar um valor nulo, logo sendo necessária a checagem.

Uma prática que auxilia bastante a evitar situações do tipo é o TDD (Test-Driven Development). Isso ocorre pelo foco na escrita de testes antes da implementação, dando uma grande clareza sobre como o software deve se comportar em diferentes situações, especialmente em fluxos alternativos e de exceção (valores nulos, listas vazias, indisponibilidade de um serviço ou outro). Outra metodologia interessante para reduzir a incidência de erros é a de Defensive Programming.

Quer alavancar sua carreira como Desenvolvedor(a) .NET?

Opa, aqui é o Luis Felipe (LuisDev), criador do blog LuisDev.

Além de Desenvolvedor .NET Sênior, eu sou instrutor de mais de 700 alunos e também tenho dezenas de mentorados.

Conheça o com mais de 800 video-aulas sobre C# e desenvolvimento de APIs com ASP NET Core, Microsserviços com ASP NET Core, Arquitetura de Software, Computação em Nuvem, SQL, HTML, CSS e JavaScript, JavaScript Intermediário, TypeScript, Desenvolvimento Front-End com Angular, e Desenvolvimento Front-end com React. Diversos mini-cursos disponíveis aos alunos e atualizações gratuitas.

Suporte dedicado, e comunidade de centenas de alunos.

Completo e online, destinado a profissionais que querem dar seu próximo passo em sua carreira como desenvolvedores .NET.

Clique aqui para ter mais informações e garantir sua vaga

O artigo cobriu algumas boas práticas na programação com C# que, quando desrespeitadas, acabam dificultando a legibilidade e manutenção do código, e também gerando bugs (no caso da checagem de objetos nulos). É comum de encontrar projetos que violem pelo menos uma delas, mas é escolha nossa de “deixar passar” ou de tomar uma ação para contribuir na qualidade de nossos projetos.

Sejamos proativos e não reativos! Até o próximo artigo.