Domanda

Ho lavorato su molti progetti in cui mi è stato dato il codice da altri per l'aggiornamento. Il più delle volte lo compilo e ricevo circa 1.000+ avvisi di compilatore. Quando vedo gli avvisi del compilatore mi fanno sentire sporco, quindi il mio primo compito è ripulire il codice e rimuoverli tutti. In genere trovo circa una dozzina di problemi come variabili non inizializzate come.

Non capisco perché le persone li lascino dentro e non abbiano compilazioni perfettamente pulite senza avvertimenti. Mi sto perdendo qualcosa? C'è qualche motivo valido per lasciarli? Qualche storia horror da condividere?

È stato utile?

Soluzione

Desidero eliminare qualsiasi avviso. Anche quelli che conosci sono innocui (se esiste una cosa del genere) ti darà una cattiva impressione a chi compilerà il codice.

È uno dei "puzzolenti" segni che avrei cercato se avessi dovuto lavorare su qualcun altro codice.

Se non errori reali o potenziali problemi futuri, sarebbe un segno di sciattezza

Altri suggerimenti

Puliscili, anche se non indicano un problema reale. Altrimenti, se viene visualizzato un avviso che indica un problema reale, non lo vedrai attraverso tutto il rumore.

Al mio lavoro, l'impostazione del compilatore per trattare gli avvisi come errori è attivata. Quindi, nessun avviso o non verrà compilato :)

Sono d'accordo che è meglio eliminare tutti gli avvisi. Se ricevi migliaia di avvisi, devi dare la priorità alle tue correzioni.

Inizia a impostare il tuo compilatore sul livello di avviso più basso. Questi avvisi dovrebbero essere i più importanti. Una volta risolti, aumenta il livello di avviso e ripeti fino a raggiungere il livello di avviso più alto. Quindi imposta le opzioni di compilazione in modo tale che gli avvisi vengano trattati come errori.

Se trovi un avviso che sospetti sia sicuro da ignorare, fai qualche ricerca per verificare la tua teoria. Solo allora disabilitalo e solo nel modo più minimale possibile. La maggior parte dei compilatori ha direttive #pragma che possono disabilitare / abilitare gli avvisi solo per una parte di un file. Ecco un esempio di 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 )

Nota che questo disabilita l'avviso solo per una singola riga di codice. L'uso di questo metodo ti consente anche di eseguire una semplice ricerca di testo del codice in futuro per apportare modifiche.

In alternativa, in genere è possibile disabilitare un particolare avviso per un singolo file o per tutti i file. IMHO questo è pericoloso e dovrebbe essere solo l'ultima risorsa.

Puliscili se possibile . Su una base di codice multi-piattaforma / multi-compilatore (ho lavorato su uno che ha compilato 7 diversi sistemi operativi con 6 diversi compilatori) non è sempre possibile però. Ho visto casi in cui il compilatore è semplicemente sbagliato (HP-UX aCC su Itanium, ti sto guardando), ma è certamente raro. Come altri notano, è possibile disabilitare l'avviso in una situazione del genere.

Molte volte ciò che è un avvertimento in questa versione del compilatore può diventare un errore nella versione successiva (chiunque esegua l'aggiornamento da gcc 3.xa 4.x dovrebbe averne familiarità), quindi puliscilo subito.

Alcuni compilatori emetteranno avvisi davvero utili che in alcuni casi diventeranno problemi: Visual C ++ 2005 e 2008 possono avvisarti di problemi a 64 bit, che oggi è un enorme vantaggio. Se hai intenzione di migrare a 64 bit, solo ripulendo questo tipo di avvisi ridurrà drasticamente il tempo di porta.

Ci sono alcuni casi in cui lascerò avvisi nel codice, o dove è impossibile ripulirli (anche se rimuovo quelli che posso). Ad esempio:

  • Se hai qualcosa su cui stai lavorando e sai che ha bisogno di più lavoro / attenzione, lasciare un avviso sul posto per indicare che questo può essere appropriato
  • Se stai compilando C ++ con / clr, ci sono diversi avvertimenti su cose che causano la generazione di codice nativo; può essere scomodo sopprimere tutti questi avvisi quando la base di codice non può essere modificata funzionalmente
  • Pulizia degli avvisi quando non si capisce cosa fa la correzione. L'ho fatto un paio di volte con l'avviso PC-Lint e ho finito per introdurre bug. Se non sai qual è l'effetto esatto della modifica (ad es .: lanci di tipo C per eliminare gli avvisi), NON farlo. Capire l'avvertimento o lasciare solo il codice è il mio consiglio.

Ad ogni modo, quelli sono i casi in cima alla mia testa dove lasciare gli avvertimenti potrebbe essere appropriato.

La parte peggiore è che quando scrivi un nuovo codice, è difficile sapere se hai introdotto accidentalmente più avvisi, poiché ce ne sono così tanti che li ignori comunque.

Il problema con la pulizia di tutti, è che ci vuole tempo che potresti avere o meno. Ma sì, generalmente dovresti ripulire il maggior numero possibile.

Lasciare avvisi nel tuo codice perché non hai tempo per ripararli è come non lavarti i denti perché non hai abbastanza tempo al mattino. È una questione basilare di igiene del codice.

Pulisci sempre i tuoi avvisi. Se hai un caso specifico in cui sai che l'avviso è ok, sopprimilo solo per quell'istanza.

Mentre alcuni avvisi possono essere benigni, la maggior parte indica un vero problema con il codice.

Se non ripulisci tutti i tuoi avvisi, l'elenco degli avvisi continuerà a crescere e i casi di problemi reali andranno persi in un mare di rumori di avviso.

Una delle caratteristiche di un programmatore davvero bravo è che il cattivo codice dà loro uno stomaco nauseato.

Mi sforzo di avere tutto il mio codice non solo pulito dal compilatore, ma anche pulito all'interno del mio IDE impostato su un livello abbastanza esigente. A volte dovrò sopprimere un'istanza di avviso se conosco meglio dello strumento, ma almeno serve anche come documentazione.

Abilito sempre tutti gli avvisi, quindi imposto che il mio progetto venga interrotto se ci sono avvisi.

Se sono presenti avvisi, è necessario controllarli tutti per assicurarsi che non vi siano problemi. Farlo ancora e ancora è una perdita di tempo. In caso contrario, si verificheranno errori nel codice.

Esistono modi per rimuovere un avviso (ad esempio #pragma argsused).

Lascia che il compilatore faccia il lavoro.

Ho lavorato con diversi sistemi embedded in cui gli avvisi causeranno instabilità, crash o danneggiamento della memoria. A meno che tu non sappia che l'avvertimento è innocuo, dovrebbe essere affrontato.

Gli avvisi sono e devono essere trattati come bug. Se non riesci a programmare abbastanza bene per sbarazzarti dei tuoi avvertimenti, probabilmente non dovresti codificare. Nel mio gruppo abbiamo preso la decisione di forzare tutti gli avvisi agli errori. Termina del tutto questa discussione e davvero, IMHO, migliora la qualità del codice.

Non mi piacciono gli avvisi. Li rimuovo il più possibile.
A volte, quando sono sotto pressione per finire il lavoro, ne lascio alcuni. Raramente li lascio però. Mi sento sporco, se ce ne sono rimasti.

La base di codice su cui lavoro ha oltre 4000 avvisi. Alcuni di loro sono problemi legittimi. Non ci viene mai dato il tempo di entrare e risolverli, né riformattare altre cose rotte ... In parte, questo perché il codice è così vecchio che precede il C ++ standardizzato. Possiamo compilare solo in VC ++ 6.

Pulisci sempre tutti gli avvisi o eliminali esplicitamente se necessario. Le impostazioni predefinite per gli avvisi dovrebbero essere le più alte possibili durante la compilazione (ad esempio livello 4 su VS).

Il mio capo che ha creato un codice che ora mantengo. Usa i flag del compilatore per nascondere i suoi avvisi di deprivazione.

Quando ho tempo, ripasso e pulisco ciò che posso.

Provo a compilare il codice con un livello abbastanza alto di avvisi e a ripulirli tutti, tranne per il "confronto firmato / non firmato". avvisi, che sono sicuro che dovrei risolvere ma che non possono mai essere disturbati.

Versione breve: in g ++ uso " -Wextra -Wno-sign-compare " e sbarazzarsi di tutti i messaggi.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top