Avvisi del compilatore

Alcuni avvisi di solito ignorano ma se lo fai, poi nel tempo si moltiplicheranno fino a quando quel giorno arriverà quando ce ne sono così tanti che ti manca l'avvertimento che conta davvero perché è nascosto nel rumore.

Risolvi immediatamente gli avvertimenti (che potrebbero includere la disattivazione delle singole regole se ritieni che 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 'volgare (pensa all'odore del codice), allora il codice dovrebbe essere rivisto.

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

Quando stavo scrivendo in C e C ++ avrei abilitato le impostazioni più severe che potevo perché volevo sapere quando qualcosa non aveva senso per il compilatore. Quando ho finito di trasmettere e controllare i valori di ritorno sarei felice perché il codice era corretto come avrei potuto farlo.

Di tanto in tanto ricevevo il codice da qualcun altro che vomitava avvertimenti. Il controllo della fonte ha mostrato che stavano ignorando le cose che erano buone prassi di programmazione in C, rendendo fragile il loro codice.

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

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

In generale 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.

Riguardo al fissare il codice di altri popoli, ciò dipende strongmente sia dalla cultura del posto di lavoro che dallo stato attuale del codice. Non puoi semplicemente modificare il codice se attiva un ciclo di ripetizione completo, come 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 avvertimento 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 le cose che esploderanno sul sito del cliente in pochi anni, dopo un cambio di codice apparentemente non correlato Somewhere Else.

Correggere gli avvertimenti. Periodo. È questo o documenta ognuno di loro, con tante pagine di spiegazioni necessarie per dimostrare che non è un rischio, accompagnato da un ordine di vendita firmato sulla tua ragazza preferita (o porn stash) se si scopre che è Era un rischio.

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

Detto questo, a volte i compilatori possono avere avvertimenti che hanno poco senso e che non possono essere facilmente risolti. Affronto questa situazione ogni giorno al lavoro con TI CodeComposer, che è un ambiente di sviluppo per DSP TI. Ho codice C ++ che compila senza avvisi in Visual Studio, ma che risulta in strani avvisi in CodeComposer, semplicemente perché il supporto di TI per lo standard C ++ potrebbe essere migliore. Fortunatamente, CodeComposer ti consente di disabilitare singoli avvisi specifici, che è quello che dobbiamo fare quando non c'è modo di correggere il codice che produce l'avviso.

Nel mio caso gli avvertimenti provengono dallo strumento PyLint e posso disabilitare un avviso su una determinata riga aggiungendo del 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 è solitamente corretto. Tuttavia, in antipati costrutti che sono generalmente una cattiva idea, ma che hanno senso in un contesto particolare. Ad esempio, si lamenta se rilevo tutte le possibili eccezioni. Di solito, è corretto, sarebbe una cattiva idea. Tuttavia, in alcuni casi, desidero rilevare tutte le eccezioni, ad esempio per inviare un rapporto di errore con i dettagli.

Quindi: in quasi tutti i casi, sbarazzati degli hack. Quando l'hack è davvero giustificato, aggiungi un commento per dirlo a PyLint.

Gli avvisi e gli errori sono messaggi che il compilatore usa per dire al programmatore "qualcosa che hai scritto non aveva senso" - la differenza tra loro è che con un avvertimento, il compilatore è disposto a fare un'ipotesi sul programmatore intenzioni, mentre con un errore, il compilatore non può nemmeno indovinare.

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

Da un punto di vista sociologico, i programmi con molti messaggi di avviso sono Windows interrotto .