Avisos do compilador

Muitos compiladores têm mensagens de aviso para avisar os programadores sobre possíveis erros de tempo de execução, lógica e desempenho; na maioria das vezes, você os corrige rapidamente, mas e os avisos não corrigíveis?

Como você lida com avisos não corrigíveis? Você reescreve uma parte do código ou reescreve-o da "maneira longa e sem truques" ou desativa todos os avisos? Qual deve ser a melhor prática?

E se você estiver editando o código de outra pessoa e este tiver avisos?

Aqui está um bom exemplo: o jQuery tem muitos avisos de JavaScript quando um navegador da classe Mozilla detectou, por que os desenvolvedores do jQ não os corrigem? Se você contribui com o jQuery, vai corrigi-los?

Geralmente, é seguro ignorar alguns avisos, mas se você fizer isso, com o tempo, eles se multiplicarão até o dia em que houver tantos que você perderá o aviso que realmente importa porque está escondido no barulho.

Corrija os avisos imediatamente (que podem incluir a desativação de regras individuais, se você achar que isso nunca é relevante para o seu contexto).

Minha opinião é que você deve ser rigoroso consigo mesmo. O compilador foi escrito por especialistas totais no idioma. Se eles estão relatando que algo está um pouco estranho (pense no cheiro do código), o código deve ser revisado.

É perfeitamente possível escrever código que seja compilado sem erros e sem avisos.

Quando escrevia em C e C ++, habilitava as configurações mais rigorosas que pude, porque queria saber quando algo não fazia sentido para o compilador. Quando terminei de lançar e verificar os valores de retorno, ficaria feliz porque o código estava o mais correto possível.

Ocasionalmente, recebia código de outra pessoa que emitia avisos. A verificação da fonte mostrou que eles estavam ignorando as boas práticas de programação em C, tornando seu código frágil.

Então, acho que existem boas razões para permitir o rigor e dedicar um tempo para consertar as coisas. Fazer o contrário é desleixado. Se eu tivesse um colega de trabalho que desligasse os avisos, passaria algum tempo com eles E o gerente explicando por que isso é realmente ruim.

Eu consertaria qualquer aviso. Se você ignorá-los e deixá-los acumular, pode realmente perder algo importante.

Geralmente, você deve esforçar-se para tornar o compilador silencioso, para que novos avisos apareçam mais. Esses avisos podem indicar erros sutis e devem ser tratados de acordo.

Em relação à fixação do código de outras pessoas, isso depende muito da cultura do local de trabalho e do estado atual do código. Você não pode simplesmente alterar o código se ele disparar um ciclo completo de reteste, como faria com o código mais tarde na fase de teste ou na produção.

Pergunte ao seu chefe e aja de acordo.

Toda vez que você vê um aviso do compilador, precisa parar e pensar se é realmente um problema esperando para explodir na sua cara no site do cliente ou algo que você pode ignorar. Pior, as coisas que você pode ignorar HOJE podem ser coisas que explodirão no local do cliente em alguns anos, depois de uma mudança de código aparentemente não relacionada em outro lugar.

Corrija os avisos. Período. É isso ou documenta cada uma delas, com tantas páginas de explicação quanto necessárias para provar que não é um risco, acompanhada de uma ordem de venda assinada com sua namorada favorita (ou pornografia), se houver Foi um risco.

Geralmente, você deseja que sua compilação seja livre de aviso. Os avisos existem por um motivo e geralmente apontam para problemas muito reais. Se você adquire o hábito de ignorar os avisos do compilador, eventualmente sua compilação terá vários deles e você perderá o aviso causado por um problema catastrófico que custará caro à sua empresa. Por outro lado, se o seu programa normalmente compila sem avisos, todos os novos avisos são notados imediatamente e podem ser resolvidos rapidamente.

Dito isto, às vezes os compiladores podem ter avisos que fazem pouco sentido e que não podem ser facilmente corrigidos. Eu enfrento essa situação todos os dias no trabalho com o TI CodeComposer, que é um ambiente de desenvolvimento para os DSPs da TI. Eu tenho código C ++ que é compilado sem avisos no Visual Studio, mas resulta em avisos estranhos no CodeComposer, simplesmente porque o suporte da TI ao C ++ padrão poderia ser melhor. Felizmente, o CodeComposer permite desativar avisos específicos individualmente, e é isso que precisamos fazer quando não há como corrigir o código que produz o aviso.

No meu caso, os avisos vêm da ferramenta PyLint e posso desativar um aviso em uma linha específica adicionando texto especial nos comentários.

Na maioria dos casos, eu não faço isso. Na maioria dos casos, altero o código para seguir o que o PyLint sugere, porque o PyLint geralmente está correto. No entanto, ao contrário de construções que geralmente são uma má idéia, mas que fazem sentido em um contexto particular. Por exemplo, reclama se eu pegar todas as exceções possíveis. Geralmente, está correto, isso seria uma má idéia. No entanto, em alguns casos, eu quero capturar todas as exceções, como para me enviar um relatório de erro com os detalhes.

Então: em quase todos os casos, livre-se dos hacks. Quando o hack for realmente justificado, adicione um comentário dizendo ao PyLint que está tudo bem.

Alguns dos benefícios do rigor não foram claramente declarados nas outras respostas:

1. Quando todos os avisos facilmente corrigíveis forem corrigidos, os avisos significativos / relevantes restantes terão mais probabilidade de aparecer.
2. Se os avisos relevantes forem encontrados e tratados dentro do prazo (antes do lançamento), os erros poderão ser evitados, levando a uma melhor satisfação do usuário final
3. A resolução do aviso geralmente leva a um código mais simples e de manutenção (por exemplo, eliminação de condições sempre verdadeiras)
4. Quando a quantidade de avisos está mais próxima de 0, é fácil concordar com a Política de Aviso Zero na equipe, que é muito fácil de automatizar no sistema de IC.
5. Ao resolver avisos do compilador, o entendimento do código do programa se aprofunda, o que pode levar a informações úteis sobre a implementação (por exemplo, descubra outros bugs ou obtenha idéias de como desenvolver o código ainda mais)
6. A compilação fica mais rápida e aumenta a produtividade diária: o IDE / compilador tem menos problemas para gerenciar e relatar, portanto, a compilação é mais rápida (isso é relevante apenas no contexto de milhares de avisos).

Existem diferenças específicas de idioma em certos tipos de avisos. Eu acho que é importante pensar e discutir sobre o tópico e, em seguida, desativar alguns avisos individuais se eles se sentirem totalmente inúteis, para que o rigor possa ser alcançado. Isso foi realizado em várias equipes da minha carreira. Mais sobre minhas experiências sobre o tema

Avisos e erros são mensagens que o compilador usa para dizer ao programador "algo que você escreveu não fazia sentido" - a diferença entre eles é que, com um aviso, o compilador está disposto a adivinhar as intenções do programador, enquanto com um erro, o compilador não consegue nem adivinhar.

Os erros do compilador serão corrigidos (não vou dizer corrigido ), mas com muita freqüência os programadores (mesmo os experientes) ignoram os avisos. O problema de ignorar os avisos é que, às vezes, o compilador pensa errado e, se você tiver mais de 1000 mensagens de aviso, é fácil perder uma mensagem de aviso indicando que o compilador está supondo que está errado.

Do ponto de vista sociológico, os programas que possuem muitas mensagens de aviso são o Windows Quebrado .