As pessoas, por sua natureza, são propensas a cometer erros. No entanto, muitas deficiências específicas dos desenvolvedores podem ser evitadas. Se um programador conseguir se livrar dos erros comuns que serão discutidos neste artigo, ele poderá escrever um código melhor e mais limpo.
A eliminação de falhas no código beneficiará não apenas aqueles que se livrarem deles, mas também aqueles programadores que precisam ler esse código. Como resultado, podemos dizer que aqueles que trabalham em equipe e se esforçam para melhorar seu código fazem isso não apenas por si mesmos, mas também por aqueles com quem trabalham.
Aqui estão algumas falhas comuns que um programador deve evitar.
1. Muitas ações na função
De acordo com o princípio de responsabilidade exclusiva, uma função deve ser responsável apenas pelo desempenho de qualquer operação. E isso deve ser apenas uma operação. Vi muitas funções que executam o carregamento, processamento e apresentação de determinados dados. Acredita-se que a implementação de tais ações seja melhor distribuída entre várias funções. Uma função carrega dados, outros processos, a terceira é responsável por sua apresentação.
A razão da importância de escrever funções que se concentram na solução de um único problema é que essa abordagem torna o código mais confiável. Suponha que, no caso acima, os dados sejam carregados de uma determinada API. Se essa API mudar, por exemplo, se uma nova versão for lançada, é altamente provável que toda a função pare de funcionar. O código que carrega os dados carregará algo errado, isso afetará o processamento e a apresentação dos dados. Para resolver o problema, primeiro você terá que encontrá-lo, descobrir o que falhou e depois editar o código de uma função grande. Se o carregamento, o processamento e a apresentação de dados forem divididos em várias funções, será muito mais fácil resolver esses problemas.
2. O projeto comentou o código
Todos viram o código, grandes fragmentos dos quais, por exemplo, contendo determinadas funções, são comentados. No entanto, ninguém sabe por que esses fragmentos ainda não foram removidos da base de código. E ninguém sabe se esses trechos de código funcionarão se não forem comentados. Mas, ao mesmo tempo, eles não são removidos. E você precisa excluí-los. A razão pela qual esse código está poluindo os projetos é porque todo mundo sugere que alguém pode precisar desse código.
Esses fragmentos de código devem ser simplesmente excluídos. E se na versão mais recente do código esses fragmentos remotos não estiverem presentes e, ao mesmo tempo, alguém realmente precisar deles, eles poderão ser encontrados no sistema de controle de versão. Observo que esta é apenas a minha opinião sobre esse assunto.
3. Nomes de variáveis incorretos
Certa vez, escrevi
um artigo que apresentava regras simples para selecionar bons nomes de variáveis. Nomes de variáveis qualitativas são extremamente importantes. O fato é que os programadores geralmente não trabalham apenas em projetos. Seus colegas precisam entender o código que escrevem. Nomes de variáveis amigáveis ajudam a melhorar a percepção do código de outra pessoa.
Repito o que disse no material acima: "Escolher bons nomes de variáveis leva tempo, mas economiza mais tempo do que leva".
4. "Números mágicos" e seqüências de caracteres
Se continuarmos nossas discussões sobre o problema de nomes obscuros de variáveis, podemos ter a idéia de usar certos valores no programa, “números mágicos” ou strings que não têm nomes e não são gravados em nenhuma variável.
Você pode aprender na
Wikipedia que “números mágicos” são chamados de práticas ruins de programação quando um valor numérico é encontrado no texto de origem e não é óbvio o que isso significa.
Dê uma olhada no seguinte exemplo de código:
for ($i = 1; $i <= 52; $i++) { ... }
Aqui o valor
52 é o "número mágico". Ninguém sabe por que esse é exatamente o número 52 e o que significa. Por que 52? Por que não 64? Talvez este seja o número de semanas em um ano?
Este código ficará muito mais claro se você o reescrever assim:
$cardDeckSize = 52; for ($i = 1; $i <= $cardDeckSize; $i++) { ... }
Agora, qualquer um entenderá que, em um ciclo, passamos por um baralho de cartas. Isso indica para outros desenvolvedores a essência do que está acontecendo, ajuda a entender o contexto da ação que está sendo executada. Além disso, essa abordagem simplifica bastante a alteração desse valor, pois, se usado em locais diferentes do programa, é definido apenas em um local no código.
O mesmo se aplica ao trabalho com strings:
if (userPasswordIsValid($user, "6yP4cZ".$password)) { ... }
O que é esse
6yP4cZ ? Parece um conjunto de caracteres aleatórios.
Reescrevemos isso:
$salt = "6yP4cZ"; if (userPasswordIsValid($user, $salt.$password)) { ... }
Mas agora tudo está muito mais claro.
5. Formatação de código imprecisa
A formatação desarrumada de código é uma "doença" para programadores iniciantes. Muitos desenvolvedores com alguma experiência tendem a concordar afirmativamente quando perguntados se conhecem um testador ou um cientista de dados que não formata bem o código. A razão para isso é a falta de experiência. As únicas exceções são aqueles programadores que usam uma linguagem como Python, na qual a formatação do código afeta a execução do programa.
Uma das maneiras mais comuns de resolver esse problema é usar um linter. Todos os IDEs modernos, além disso, suportam a capacidade de formatar automaticamente o código. Às vezes, essa funcionalidade é implementada por meio de plug-ins que você precisa instalar e, às vezes, é incluída nos recursos padrão do IDE.
6. Valores codificados no código
Se os valores são codificados em programas, isso significa que os dados são incorporados diretamente no código-fonte ou em outros objetos semelhantes. O oposto dessa abordagem é obter dados de fontes externas ou gerá-los durante a execução do programa.
Os valores definidos não permitem uma configuração fácil do programa. Eles são, por assim dizer, "esculpidos em pedra". Isso é considerado um antipadrão ou, no mínimo, indica problemas óbvios no código.
Na maioria das vezes, as senhas e os caminhos dos arquivos são codificados. Eles fazem isso por várias razões, às vezes podem até ser justificados.
Por exemplo, muitos valores codificados podem ser vistos em alguns exemplos de código responsáveis pela autenticação em serviços externos ou APIs. É melhor não fazer isso.
Se alguém notou o uso frequente de valores codificados, deve avaliar criticamente seu trabalho. O fato é que geralmente o uso de tais valores não é a melhor maneira de resolver certos problemas.
Caros leitores! Quais deficiências no código você encontrou?
