5 Dicas para um Código mais Limpo

Versão em inglês

Atualmente, a área de tecnologia tem um enorme dinamismo e isso significa que os desenvolvedores estão mudando seus empregos mais do que nunca.

Nós realmente escrevemos código para uma máquina? Não devemos esquecer que existem outras pessoas escrevendo código na mesma base de código que a nossa.

Existem muitas opiniões e estruturas que definem um código como “bom”.

Não é necessariamente o código mais curto, mas uma maneira melhor de expressar o que seu código significa.

Todos os exemplos abaixo foram feitos na linguagem Ruby

1. Nomeando as Coisas

Por que nomear as coisas é importante? Imagine que você está entrando em uma nova empresa e tentando descobrir o que significa esse trecho de código em um contexto de filmes:

É clara a intenção do código? A única coisa que podemos assumir é que estamos pegando os primeiros elementos de um array, mas o que é esse array? O que significa count?

E agora:

Melhor, certo?

Nomear as coisas melhora a comunicação entre todos que estão “codando” na mesma base de código e quanto mais explícito você for é melhor.

2. Melhorando Condicionais

Temos algumas maneiras de melhorar as condicionais do código, por exemplo:

Você imagina uma maneira melhor de fazer esse switch case? Parece que esses valores deveriam ser constantes, então… Que tal isso:

Traduzimos todo o switch case em um hash, e agora ficou mais fácil de entender.

O próximo pode salvar sua vida em muitas vezes, e é recomendado pelo Ruby Style Guides 😊

Você já ouviu falar sobre early return ou guard clause?

Sequência de comandos para fazer o hadouken

“If-Else Hadouken” — REFERÊNCIA DO MEME AQUI:

Quando você se depara com esse trecho de código é difícil entender o que está acontecendo, não é? Calma, podemos melhorar:

O “If-Else Hadouken” acabou. Tudo o que fizemos foi dividir as etapas em pequenos pedaços e acabar com a bagunça das condicionais. E tem muitos benefícios:

• É mais fácil de manter
• Evita o esforço cognitivo
• Melhora a legibilidade

Acredite, se você tentar melhorar as condicionais, sua vida (e a dos outros) será melhor

3. Tratamento de Erros

O tratamento de erros é importante para fazer as coisas funcionarem, se você não fizer isso corretamente, se alguma exceção surgir, será mais difícil entender o que está acontecendo em determinado contexto.

Imagine essa situação, existe uma notificação crítica pro contexto, e se ocorrer algum erro na requisição HTTP? Nesse caso, ele lançará alguma exceção do cliente HTTP (se o cliente lidar com isso) e será difícil entender o que está acontecendo.

Você deve capturá-lo e determinar o que fará com o erro:

💡 Quando você não especifica o erro em Ruby, ele irá capturar qualquer erro que estenda a classe StandardError, para mais informações verifique a hierarquia de erros em Ruby

⚠️ Nunca especifique o erro Exception ao capturar, se você fizer isso, todos os erros do seu sistema podem ser capturados. Quanto mais específico for o seu erro, melhor para determinar o que você precisa fazer, é o seu fallback.

4. Evitando Comentários Desnecessários

Parece ser simples, não é? Alguns dias atrás eu estava “codando” em um sistema legado e me deparei com o seguinte:

Beleza, agora me fala… Você sabe o que significa C57? Passei um tempinho pra perceber que não significa NADA 😅

Meme indicando um comentário desnecessário

Em geral, comentários desnecessários podem causar confusão e gastar tempo e, hoje em dia, tempo é dinheiro…

5. Melhorando os Testes

Todos sabemos que testar é uma coisa boa, os testes podem evitar muitos bugs e ser um complemento para a documentação

Mas e escrever bons testes?

Quando começo a escrever algum teste, penso que preciso ser claro porque muitos desenvolvedores usarão esse teste para entender as regras da aplicação. Então, eu sigo o padrão Four-Phase Test:

Testes podem ser separados em quatro etapas: Arrange, Act, Assert e Teardown.

Que podem ser resumidos em: preparar tudo para o teste, estimular o que será testado, verificar se o resultado é o esperado e limpar tudo o que foi feito durante aquele teste.

💡 Em Ruby, quando estamos fazendo transações no banco de dados, o teardown ocorre “automagicamente”, fazendo um rollback a cada transação durante o fim do teste

Exemplo:

É fácil ver cada etapa do teste de unidade, dividir em partes menores torna as coisas menos complicadas.

Conclusão

Essas dicas podem guiá-lo na sua jornada de desenvolvedor, seu código ficará mais limpo e mais importante: ajudará outros desenvolvedores a entender seu código.

E não se esqueça:

Os programadores devem evitar deixar pistas falsas que obscureçam o significado do código. (tradução literal)
— Robert C. Martin

Obrigado pela leitura!! 🍻