loading...
Cover image for Code Smells, não deixa para depois.

Code Smells, não deixa para depois.

joaberamone profile image Joabe Ramone ・3 min read

Quero abordar um tópico que é na maioria das vezes, esquecido por nós programadores. Passa tão despercebido no nosso dia a dia que futuramente podem causar problema mais profundos. Na maioria das vezes, queremos entregar a tarefa no prazo estimado e nem prestamos atenção que nosso código pode estar com algo estranho, aquele cheirinho de “não tem problema deixar isso ai”. E assim o código vai passando de mão em mão até que a coisa fica grande. E são problemas tão simples que com 2 ou 3 minutos você pode resolver.

Quero abordar sobre “Code Smells” pois recentemente corrigi vários códigos antigos em um projeto que faço parte da empresa onde trabalho. Eles estavam com cheiro ruim faz tempo, e com isso, aprendi algumas boas práticas a serem usadas.

Espero que esse post seja um alerta e que possa agregar algo no seu trabalho ou aprendizado.

Vale reforçar que estou começando a publicar recentemente e meu propósito é poder ajudar a comunidade DEV e gerar conteúdo em português. Qual quer crítica ou sugestão podem deixar nos comentários que será de grande ajuda, Valeu!

Bom, vamos ao que interessa. Eu separei dois assuntos para ser bem breve. Primeiro vamos falar de :

Variáveis não devem ser sombreadas

Substituir ou obscurecer uma variável declarada em um escopo externo pode impactar fortemente a legibilidade e, portanto, a manutenção de um trecho de código.

Sombras podem confundir

Provavelmente você já deve ter visto ou até mesmo feito um código que você recebia uma variavel por parametro, mas tinha o mesmo nome de outra variavel na mesma classe ou espoco.

var y;
var x;
function soma(x, y) {
    return x + y;
}  

Acabei percebendo que isso é comum nos códigos, pelo fato de estar dando o mesmo nome daquela que já foi declarada no escopo, podendo estar garantindo mais facilidade para identifica-lo. Ou não, isso pode ser um grande problema para outra pessoa ao ler o código.
Essa prática, pode levar as pessoas a introduzirem bugs no código. Porque pensam que estão usando uma variável, mas na verdade estão usando outra.
Pode parecer besta, mas para um código complexo e que não foi você quem o fez. Pode ser que não .

O segundo assunto é um pouco mais difícil de acontecer com frequência, ou não.

Seções de código não devem ser comentadas

"Os programadores não devem comentar o código, pois isso incha os programas e reduz a legibilidade."

comentários em blocos

Sabemos que os comentários podem ser utilizados para identificar ou explicar algo que está acontecendo no código, por mais que seja uma má prática, muitas vezes usamos. Mas os comentários começam a se tornar um problema quando comentamos seções de código, isso torna o complexo e difícil de entender. Sendo que procuramos fazer o código mais prático possível e aplicando boas práticas para melhorar a leitura das pessoas e não das máquinas.
O código não utilizado deve ser excluído e pode ser recuperado do histórico de controle de origem, se necessário.

Considerações finais

Por hora é isso pessoal, quero poder fazer outros post’s abortando sobre “Code Smells” pois acho que é de grande importância. Existe muito mais prática a ser estudada, assim que eu for descobrindo e aprendendo quero estar gerando conteúdo para publicar aqui.

Para mais informações acesse:

https://wiki.sei.cmu.edu/confluence/display/c/DCL01-C.+Do+not+reuse+variable+names+in+subscopes

https://wiki.sei.cmu.edu/confluence/display/java/DCL51-J.+Do+not+shadow+or+obscure+identifiers+in+subscopes

Discussion

pic
Editor guide