Avvertenze del compilatore

Molti compilatori hanno messaggi di avviso per avvertire i programmatori di potenziali errori di runtime, logica e prestazioni, la maggior parte delle volte, li risolvi rapidamente, e che dire di avvisi non correggibili?

Come gestite gli avvisi non risolvibili? Riscrivi una parte del codice o lo riscrivi in ​​"modo lungo e senza hack" o disabiliti tutti gli avvisi? Quale dovrebbe essere la migliore pratica?

Che cosa succede se si sta modificando il codice di qualcun altro e il suo codice contiene avvisi?

Ecco un buon esempio: jQuery ha rilevato molti avvisi JavaScript quando viene rilevato un browser di classe Mozilla, perché gli sviluppatori jQ non li risolvono? Se contribuisci a jQuery, li risolverai?

Alcuni avvisi sono generalmente sicuri da ignorare, ma se lo fai, nel tempo si moltiplicheranno fino a quando arriva quel giorno in cui ce ne sono così tanti che ti manca l'unico avviso che conta davvero perché è nascosto nel rumore.

Correggi immediatamente gli avvisi (che possono includere la disabilitazione di singole regole se ritieni che non sia mai rilevante per il tuo contesto).

La mia opinione è che dovresti essere severo con te stesso. Il compilatore è stato scritto da esperti totali nella lingua. Se stanno segnalando che qualcosa è un po 'instabile (si pensi all'odore del codice), il codice dovrebbe essere rivisto.

È del tutto possibile scrivere codice che viene compilato senza errori e senza avvisi.

Quando scrivevo in C e C ++ abilitavo le impostazioni più rigide che potevo perché volevo sapere quando qualcosa non aveva senso per il compilatore. Quando ho finito di trasmettere e verificare i valori restituiti, sarei felice perché il codice era il più corretto possibile.

Occasionalmente ricevevo codice da qualcun altro che emetteva avvisi. Il controllo della fonte ha mostrato che stavano ignorando le cose che erano buone pratiche di programmazione in C, rendendo il loro codice fragile.

Quindi, penso che ci siano buone ragioni per abilitare la rigidità e prendersi il tempo per sistemare le cose. Fare altrimenti è sciatto. Se avessi un collega che ha disattivato gli avvisi, passerei un po 'di tempo con loro E il manager spiegherà perché è davvero una brutta cosa.

Vorrei correggere qualsiasi avviso. Se li ignori e li lasci accumulare, potresti davvero perdere qualcosa di importante.

Generalmente dovresti cercare di rendere silenzioso il compilatore, in modo che i nuovi avvisi mostrino di più. Questi avvisi possono indicare bug sottili e devono essere gestiti di conseguenza.

Per quanto riguarda la correzione del codice di altre persone, dipende fortemente sia dalla cultura del luogo di lavoro sia dallo stato attuale del codice. Non puoi semplicemente modificare il codice se innesca un ciclo di test completo, come farebbe per il codice in ritardo nella fase di test o in produzione.

Chiedi al tuo capo e agisci di conseguenza.

Ogni volta che vedi un avviso del compilatore, devi fermarti e pensare se è davvero un problema in attesa di esplodere in faccia al sito del cliente o qualcosa che puoi ignorare. Peggio ancora, le cose che puoi ignorare OGGI potrebbero essere cose che esploderanno nel sito del cliente in pochi anni, dopo una modifica del codice apparentemente non correlata Somewhere Else.

Correggi gli avvisi. Periodo. È quello o documenta ognuno di essi, con tutte le pagine di spiegazione necessarie per dimostrare che non è un rischio, accompagnato da un ordine di vendita firmato sulla tua ragazza preferita (o scorta di porno) se si scopre che Era un rischio.

In generale, vuoi che la tua build sia priva di avvisi. Gli avvisi sono lì per un motivo e spesso indicano problemi molto reali. Se prendi l'abitudine di ignorare gli avvisi del compilatore, alla fine la tua build ne avrà una tonnellata, e perderai l'unico avvertimento causato da un problema catastrofico che costerà caro alla tua azienda. D'altra parte, se il tuo programma normalmente si compila senza avvisi, ogni nuovo avviso viene immediatamente notato e può essere risolto rapidamente.

Detto questo, a volte i compilatori possono avere avvisi che hanno poco senso e che non possono essere facilmente risolti. Devo affrontare questa situazione ogni giorno al lavoro con TI CodeComposer, che è un ambiente di sviluppo per DSP TI. Ho un codice C ++ che viene compilato senza avvisi in Visual Studio, ma che provoca strani avvisi in CodeComposer, semplicemente perché il supporto di TI per C ++ standard potrebbe essere migliore. Fortunatamente, CodeComposer consente di disabilitare singoli avvisi specifici, che è ciò che dobbiamo fare quando non è possibile correggere il codice che genera l'avviso.

Nel mio caso, gli avvisi provengono dallo strumento PyLint e posso disabilitare un avviso su una riga specifica aggiungendo un testo speciale nei commenti.

Nella maggior parte dei casi, non lo faccio. Nella maggior parte dei casi cambio il codice per seguire ciò che PyLint suggerisce perché PyLint è generalmente corretto. Tuttavia, in antipatie costrutti che sono generalmente una cattiva idea, ma che hanno senso in un contesto particolare. Ad esempio, si lamenta se colgo tutte le possibili eccezioni. Di solito, è corretto, sarebbe una cattiva idea. Tuttavia, in alcuni casi, voglio cogliere tutte le eccezioni, come l'invio di un rapporto di errore con i dettagli.

Quindi: in quasi tutti i casi, sbarazzati degli hack. Quando l'hacking è davvero giustificato, aggiungi un commento dicendo a PyLint che va bene.

Alcuni dei vantaggi del rigore non sono stati chiaramente indicati nelle altre risposte:

1. Quando tutti gli avvisi facilmente risolvibili sono stati corretti, è più probabile che vengano visualizzati gli avvisi significativi / rilevanti rimanenti.
2. Se gli avvisi pertinenti vengono rilevati e gestiti in tempo (prima del rilascio), i bug possono essere evitati, portando così a una migliore soddisfazione dell'utente finale
3. La risoluzione dell'avviso di solito porta a un codice più gestibile e più semplice (ad esempio, l'eliminazione di condizioni sempre vere)
4. Quando la quantità di avvisi è più vicina a 0, è facile concordare la politica di avviso zero nel team, che è molto facile da automatizzare nel sistema CI.
5. Quando si risolvono gli avvisi del compilatore, la comprensione del codice del programma si approfondisce, il che può portare a informazioni utili sull'implementazione (ad esempio, scoprire altri bug o ottenere idee su come sviluppare ulteriormente il codice)
6. La compilazione aumenta, la produttività giornaliera aumenta: IDE / compilatore ha meno problemi su cui gestire e riferire, quindi la compilazione è più veloce (questo è rilevante solo nel contesto di migliaia di avvisi).

Esistono differenze specifiche della lingua su alcuni tipi di avvisi. Penso che sia importante pensare e discutere sull'argomento e quindi disabilitare alcuni avvisi individuali se si sentono totalmente inutili in modo che la rigidità possa essere raggiunta. Questo è stato realizzato in diverse squadre della mia carriera. Maggiori informazioni sulle mie esperienze sull'argomento

Avvertimenti ed errori sono messaggi che il compilatore usa per dire al programmatore "qualcosa che hai scritto non ha senso" - la differenza tra loro è che con un avvertimento, il compilatore è disposto a fare un'ipotesi sulle intenzioni del programmatore, mentre con un errore, il compilatore non può nemmeno fare un'ipotesi.

Gli errori del compilatore verranno risolti (non dirò risolti ), ma troppo spesso i programmatori (anche quelli esperti) ignoreranno gli avvisi. Il problema con l'ignorare gli avvisi è che a volte il compilatore indovina erroneamente e se hai più di 1000 messaggi di avviso, è facile perdere un messaggio di avviso che indica che il compilatore sta indovinando sbagliato.

Da un punto di vista sociologico, i programmi che hanno molti messaggi di avviso sono Windows rotto .