Avisos do compilador C/C++:você limpa todo o seu código para removê-los ou deixá-los lá?

Question

Trabalhei em muitos projetos nos quais recebi código de outras pessoas para atualizar.Na maioria das vezes eu compilo e recebo mais de 1.000 avisos do compilador.Quando vejo avisos do compilador, eles me fazem sentir sujo, então minha primeira tarefa é limpar o código e remover todos eles.Normalmente encontro cerca de uma dúzia de problemas como variáveis ​​não inicializadas.

Não entendo por que as pessoas os deixam e não têm compilações perfeitamente limpas e sem avisos.Estou esquecendo de algo?Existe algum motivo válido para simplesmente deixá-los?Alguma história de terror para compartilhar?

Answer 1

Eu limparia qualquer aviso.Mesmo aqueles que você sabe que são inofensivos (se tal coisa existir) darão uma má impressão sua a quem irá compilar o código.

É um dos sinais "fedorentos" que eu procuraria se tivesse que trabalhar no código de outra pessoa.

Se não fossem erros reais ou possíveis problemas futuros, seria um sinal de desleixo

Answer 2

Limpe-os, mesmo que não indiquem um problema real.Caso contrário, se um aviso de que faz indicar que um problema real aparece, você não o verá em meio a todo o barulho.

Answer 3

No meu trabalho, a configuração do compilador para tratar avisos como erros está ativada.Portanto, sem avisos, ou não será compilado :)

Answer 4

Concordo que é melhor eliminar todos os avisos.Se estiver recebendo milhares de avisos, você deve priorizar suas correções.

Comece configurando seu compilador para o nível de aviso mais baixo.Esses avisos devem ser os mais importantes.Quando eles forem corrigidos, aumente seu nível de aviso e repita até atingir o nível de aviso mais alto.Em seguida, defina suas opções de compilação de forma que os avisos sejam tratados como erros.

Se você encontrar um aviso que suspeita ser seguro ignorar, faça uma pesquisa para verificar sua teoria.Só então desative-o e apenas da maneira mínima possível.A maioria dos compiladores tem #pragma diretivas que podem desabilitar/habilitar avisos para apenas uma parte de um arquivo.Aqui está um exemplo do Visual C++:

typedef struct _X * X; // from external header, not 64-bit portable

#pragma warning( push )
#pragma warning( disable: 4312 ) // 64-bit portability warning
X x = reinterpret_cast< X >( 0xDDDDDDDD ); // we know X not 64-bit portable
#pragma warning( pop )

Observe que isso desativa o aviso apenas para uma única linha de código.Usar esse método também permite que você faça pesquisas simples de texto em seu código no futuro para fazer alterações.

Alternativamente, você geralmente pode desabilitar um aviso específico para um único arquivo ou para todos os arquivos.IMHO, isso é perigoso e deve ser apenas o último recurso.

Answer 5

Limpe-os se possível.Em uma base de código multiplataforma/multicompilador (trabalhei em um que compilou em 7 sistemas operacionais diferentes com 6 compiladores diferentes), isso nem sempre é possível.Já vi casos em que o compilador é apenas errado (HP-UX aCC no Itanium, estou olhando para você), mas isso é raro.Como outros observam, você pode desativar o aviso em tal situação.

Muitas vezes o que é um aviso nesta versão do compilador pode se tornar um erro na próxima versão (qualquer pessoa atualizando do gcc 3.x para 4.x deve estar familiarizado com isso), então limpe-o agora.

Alguns compiladores emitirão avisos realmente úteis que se tornarão problemas em determinadas circunstâncias - o Visual C++ 2005 e 2008 podem alertá-lo sobre problemas de 64 bits, o que é um ENORME benefício hoje em dia.Se você tem planos de migrar para 64 bits, apenas limpar esses tipos de avisos reduzirá drasticamente o tempo de portabilidade.

Answer 6

Há alguns casos em que deixarei avisos no código ou em que será inviável limpá-los (embora eu remova os que posso).Por exemplo:

• Se você tem algo em que está trabalhando e sabe que precisa de mais trabalho/atenção, deixar um aviso para indicar isso pode ser apropriado
• Se você estiver compilando C++ com /clr, há vários avisos sobre coisas que causam a geração de código nativo;pode ser complicado suprimir todos esses avisos quando a base de código não pode ser alterada funcionalmente
• Limpando avisos quando você não entende o que a correção faz.Já fiz isso algumas vezes com aviso do PC-Lint e acabei introduzindo bugs.Se você não sabe qual é o efeito exato da mudança (por exemplo:Conversões estilo C para eliminar avisos), NÃO faça isso.Descobrir o aviso ou deixar o código em paz é meu conselho.

De qualquer forma, esses são os casos que me ocorreram em que deixar avisos pode ser apropriado.

Answer 7

A pior parte é que quando você escreve um novo código, é difícil saber se você introduziu acidentalmente mais avisos, já que são tantos que você simplesmente os ignora de qualquer maneira.

O problema de limpar todos eles é que leva um tempo que você pode ou não ter.Mas sim, geralmente você deve limpar o máximo que puder.

Answer 8

Deixar avisos em seu código porque você não tem tempo para corrigi-los é como não escovar os dentes porque não tem tempo suficiente pela manhã.É uma questão básica de higiene do código.

Answer 9

Sempre limpe seus avisos.Se você tiver um caso específico em que sabe que o aviso está correto, suprima-o apenas para essa instância.

Embora alguns avisos possam ser benignos, a maioria significa um problema real com o código.

Se você não limpar todos os seus avisos, a lista de avisos continuará a crescer e os casos reais de problemas serão perdidos em um mar de ruídos de aviso.

Answer 10

Uma das características de um programador realmente bom é que código ruim lhe dá enjôo no estômago.

Eu me esforço para ter todo o meu código não apenas limpo no compilador, mas também limpo dentro do meu IDE definido em um nível bastante exigente.Às vezes, precisarei suprimir uma instância de aviso se souber melhor do que a ferramenta, mas pelo menos isso também serve como documentação.

Answer 11

Eu sempre habilito todos os avisos e, em seguida, defino meu projeto para interromper a construção se houver algum aviso.

Se houver avisos, será necessário verificar cada um deles para garantir que não haja nenhum problema.Fazer isso repetidamente é uma perda de tempo.Não fazer isso implica que erros surgirão em seu código.

Existem maneiras de remover um aviso (por exemplo,#pragma argumentos usados).

Deixe o compilador fazer o trabalho.

Answer 12

Trabalhei com vários sistemas embarcados onde os avisos resultariam em instabilidade, travamento ou corrupção de memória.A menos que você saiba que o aviso é inócuo, ele deve ser tratado.

Answer 13

Os avisos são e devem ser tratados como bugs.Se você não consegue codificar bem o suficiente para se livrar dos avisos, provavelmente não deveria codificar.No meu grupo tomamos a decisão de forçar todos os avisos a erros.Isso encerra completamente esta discussão e realmente, IMHO, melhora a qualidade do código.

Answer 14

Não gosto de avisos.Eu os removo tanto quanto possível.
Às vezes, quando estou sob pressão para terminar o trabalho, deixo alguns deles.Eu raramente os deixo.Eu me sinto como você, sujo se sobrar algum.

Answer 15

A base de código em que trabalho tem mais de 4.000 avisos.Alguns deles são problemas legítimos.Nunca temos tempo para consertá-los, nem refatorar outras coisas quebradas...Em parte, isso ocorre porque o código é tão antigo que é anterior ao C++ padronizado.Só podemos compilar em VC++ 6.

Answer 16

Sempre limpe todos os avisos ou suprima-os explicitamente, se necessário.As configurações padrão para avisos devem ser as mais altas possíveis durante a compilação (nível 4 no VS, por exemplo).

Answer 17

Meu chefe, que criou alguns códigos que agora mantenho.Ele usa sinalizadores de compilador para ocultar seus avisos de depreciação.

Quando tenho tempo, limpo o que posso.

Answer 18

Tento compilar o código com um nível bastante alto de avisos e limpá-los todos, exceto os avisos de "comparação assinada/não assinada", que tenho certeza que devo corrigir, mas nunca posso ser incomodado.

Versão curta:No g++ eu uso "-Wextra -Wno-sign-compare" e me livro de todas as mensagens.