modi pericolosi di rimozione di avvisi del compilatore?

Question

mi piace forzare una politica di nessun avviso quando controllo il codice di qualcuno. Eventuali avvisi che appaiono devono essere esplicitamente documentata come a volte non è facile da rimuovere alcuni avvisi o potrebbe richiedere troppi cicli o di memoria ecc.

Ma c'è un down-side a questa politica e che la rimozione avvertimenti in modi che sono potenzialmente pericolose, cioè il metodo utilizzato effettivamente nasconde il problema piuttosto che ripara.

Quello di cui sono più acutamente consapevoli è esplicitamente getta che potrebbero nascondere un bug.

Quali altri modi potenzialmente pericolosi di rimozione di avvisi del compilatore in C (++) ci sono che dovrei guardare fuori per?

Answer 1

const correttezza può causare alcuni problemi per i principianti:

// following should have been declared as f(const int & x)
void f( int & x ) {
  ...
}

seguito:

// n is only used to pass the parameter "4"
int n = 4;
// really wanted to say f(4)
f( n );

Edit1: In una vena un po 'simile, segnando tutte le variabili membro come mutevole , in quanto il codice li cambia spesso quando const correttezza dice che in realtà non dovrebbe

Edit2:. Un altro che ho incontrato (possibilmente da programmatori Java) è di virare throw () specifiche su funzioni, se potevano in realtà gettare o no

Answer 2

Bene, c'è il modo più ovvio - disabilitazione un'avvertenza specifica per le parti del codice:

#pragma warning( disable : 4507 34 )

EDIT: Come è stato sottolineato nei commenti, a volte è necessario utilizzare nei casi in cui si sa che gli avvertimenti sono OK (se non fosse una funzione utile, non ci sarebbe stato alcun motivo per metterlo in innanzitutto). Tuttavia, è anche un modo molto semplice per "ignora" avvisi in codice e ancora farlo per compilare in silenzio, che è ciò che la domanda iniziale era di circa.

Answer 3

Credo che sia una questione delicata. La mia opinione è che le avvertenze devono essere controllati attentamente per vedere se il codice è corretto / fa ciò che è destinato. Ma spesso non è corretto il codice che produrrà gli avvertimenti, e cercando di eliminarli basta convolutes il codice o costringe una riscrittura in modo meno naturale.

Ricordo in una versione precedente avevo codice corretto e solido che ha prodotto un paio di avvertimenti, e collaboratori iniziato a lamentarsi di questo. Il codice era molto più pulito e ha fatto quello che è stato intented. Alla fine il codice è andato sulla produzione con le avvertenze.

Inoltre, le diverse versioni del compilatore produrranno vari avvisi, in modo che diventi più inutile applicare una politica "nessun avviso" quando il risultato dipende l'umore degli sviluppatori del compilatore.

Voglio sottolineare quanto sia importante è quello di controllare tutti gli avvertimenti, almeno una volta.

A proposito io sviluppo in C e C ++ per sistemi embedded.

Answer 4

Commentando out (o, peggio, l'eliminazione) il codice che genera l'avviso. Certo, l'avvertimento va via, ma tu sei più di un po 'probabile finire con il codice che non fa ciò che si intende.

Answer 5

Ho anche applicare una regola di non-avvertimenti, ma hai ragione che non si può semplicemente rimuovere l'avviso senza un'attenta considerazione. E ad essere onesti, a volte ho lasciato le avvertenze in per un po 'perché il codice è stato giusto. Alla fine ho pulirlo in qualche modo, perché una volta che si dispone di più di una dozzina di avvisi nella build, la gente smettere di prestare attenzione a loro.

Quello che hai descritto non è un problema unico per gli avvisi. Non posso dirvi quante volte vedo qualcuno bug-fix per incidente di essere "ho aggiunto un paio di controlli NULL". Bisogna andare alla radice: Qualora tale variabile essere NULL? Se no, perché è stato?

Questo è il motivo per cui abbiamo le revisioni del codice.

Answer 6

Il rischio più grande sarebbe che qualcuno avrebbe trascorso ore di tempo di sviluppo per risolvere un avvertimento minore che non ha alcun effetto sul codice. Sarebbe uno spreco di tempo. A volte è solo più facile da mantenere un avvertimento e aggiungere una riga di commento che spiega il motivo per cui si verifica l'avviso. (Fino a quando qualcuno ha il tempo per risolvere questi avvertimenti banali.)

Nella mia esperienza, risolvendo le avvertenze banali spesso aggiunge altri due giorni di lavoro per gli sviluppatori. Coloro che potrebbe fare la differenza tra la finitura prima e dopo la scadenza.