Code Smells, 아니오 deixa para depois.

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. 이 문제는 2개 또는 3분 동안 해결해야 하는 간단한 문제입니다.

Quero abordar sobre "Code Smells"pois latestemente 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 latestemente 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 commentá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.



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 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 of fez. Pod 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."



의견을 제시할 수 있는 방법은 식별할 수 없거나 설명할 수 있는 지식이 없는 경우입니다. Mas os commentá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 codigo não utilizado deve ser excluído e pode ser recuperado do histórico de controle de origem, se necessário.

고려사항

Por hora é isso pessoal, quero poder fazer outros post's abortando sobre "Code Smells"pois acho que é de 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 accesse:

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