Não ignore os avisos do compilador, a menos que...
Escrito por Carlos B. Feitoza Filho | |
Categoria: Artigos | |
Categoria Pai: Addicted 2 Delphi! | |
Acessos: 1958 |
Este texto é uma tradução/versão brasileira do texto original escrito por Bruce McGee disponível aqui. Eu recomendo que você prestigie também o autor original vendo e curtindo outros de seus artigos em seu site https://glooscapsoftware.blogspot.com.
Uma das vantagens de usar um compilador moderno é que ele pode gerar dicas e avisos que sugerem melhorias ou destacam possíveis bugs em seu código. Vale a pena prestar atenção.
Este post foi inspirado por uma discussão sobre "melhores práticas de programação" em um grupo de Delphi no Facebook. Fiquei surpreso ao ler que alguns desenvolvedores não achavam que as dicas e avisos do compilador eram tão importantes e até mesmo os ignoravam por completo, mas claro, é o Facebook, então talvez isso não seja uma regra, entretanto eu herdei mais de um projeto que estava cheio avisos e dicas, então isso acontece com mais frequência do que deveria. Eu dou a devida atenção aos avisos e dicas e considero isso uma questão de "higiene de código".
Se o seu código produz uma tonelada de dicas e avisos, há uma boa chance de que haja erros evitáveis nesse código ou, em outras palavras, resolvê-los é uma maneira fácil de corrigir bugs potencialmente obscuros e difíceis de solucionar. Mesmo se você achar que alguns deles são benignos, eles adicionam muito ruído e obscurecem problemas mais sérios. Se você quiser, pode desativar todas as dicas e avisos, mas isso é ainda pior do que simplesmente ignorá-los. É como encobrir a luz de problema geral do seu carro, o problema não desaparece e na verdade, provavelmente vai piorar. Outras pessoas vão para o outro lado e consideram quaisquer avisos como erros. Eu não faço isso, mas você tem que respeitar estas pessoas e seu compromisso com a excelência de seus códigos.
Eu recomendo fortemente tratar todos os avisos e dicas...
...a menos que ...
Existem muito poucas regras absolutas, mas existem muitas regras e convenções do tipo "a menos que você tenha uma boa razão para fazer o contrário", que são difíceis de aprender, mas que os desenvolvedores devem seguir. Exceto with, não use with[1]!
Há alguns casos em que você não precisa prestar muita atenção às dicas e avisos. A seguir estão os principais.
Código descartável
Se você estiver criando uma prova de conceito ou apenas mexendo para descobrir como fazer algo funcionar, evidentemente você não precisa se preocupar muito em tornar esse código "pronto para produção". Se algum desses códigos se tornar um aplicativo real, aí sim ele precisará ser limpo.
Código de outra pessoa
Se você estiver usando uma biblioteca ou unidade de terceiros que gera dicas e avisos e não quiser alterar este código, faça uma compilação completa (build ou build all), copie os arquivos .dcu apropriados para uma pasta separada e atualize o Library Path (global) ou o Search Path (projeto) de forma que ele aponte para a posta onde estão estes arquivos. Dessa forma quando você recompilar ou reconstruir (build) seu projeto as mensagens de aviso e dicas não vão mais sobrecarregar seu log de compilação.
Avisos específicos
No caso de você ter certeza de que um aviso não se aplica a você, você pode ignorá-lo seletivamente nas opções do projeto. A única vez que realmente faço isso é quando tenho certeza de que um aplicativo só suportará uma única plataforma, como o Windows. Eu desativo explicitamente os avisos "Platform Symbol" e "Platform Unit".
Como último recurso...
Eu não gostaria de sugerir esse tipo de coisa, mas se, por algum motivo, você não puder ou não quiser alterar um trecho de código complicado para remover uma dica ou aviso, em vez de desativá-los para todo o projeto, você pode usar as diretivas de compilação $HINTS ou $WARNINGS em torno de um bloco de código específico para suprimi-las. Ou, melhor ainda, suprima um aviso específico usando a diretiva de compilador $WARN.
Se você tiver que fazer isso, e isso é um GRANDE SE, considere usar essas diretivas em um bloco de código tão pequeno quanto possível e talvez inclua um comentário para explicar por que os avisos estão sendo suprimidos. Ou um comentário TO-DO para lembrar seu futuro eu de limpar o código corretamente.
Indo além, com a análise de código estático
As mensagens do compilador são bastante conservadoras e limitadas a problemas técnicos no próprio código. As ferramentas de análise de código estático também fazem isso, mas também analisam um projeto como um todo e fazem sugestões com base em padrões de desenvolvimento de software bem conhecidos e potencialmente problemáticos. Eles podem ser descritos como sendo "opinativos". Isso inclui coisas como métodos excessivamente longos ou complexos que podem ser refatorados, código duplicado, código inseguro, possíveis vazamentos de memória, etc.
A primeira (até onde eu sei) ferramenta de análise estática foi o Lint, criado no Bell Labs em 1978 para a linguagem de programação C. Hoje, existem implementações para quase qualquer linguagem, incluindo Delphi.
Algumas destas ferramentas já vem com o Delphi:
- Method Toxicity Metrics
- Audits and Metrics (mais antigo, mas ainda é bastante útil)
E aqui estão algumas opções comerciais:
- Peganza Pascal Analyzer e seu plugin para a IDE, Pascal Expert
- TMS FixInsight
Caso você tenha outras sugestões, escreva nos comentários do final deste artigo 😉
Conclusão
Dar a devida atenção às dicas e avisos do compilador na primeira oportunidade pode melhorar a qualidade do seu código e evitar que você acumule "dívidas técnicas". Mesmo assim, você ainda precisa ter cuidado, pois qualquer alteração de código tem o potencial de introduzir novos bugs, portanto, use boas práticas de manutenção de software e certifique-se de entender uma alteração antes de executá-la. O melhor é sempre tentar alterar apenas o código que você tem certeza que será testado.
1 | Quando eu li isso eu só me lembrei de Alan "Bruto do Delphi" Bariani 🤣 |