È buona norma evitare avvertimenti e avvisi?

if I turn on the warnings and notices on these live production websites, they'll be overloaded with them.

Dovresti sempre avere gli avvisi attivati al massimo livello in fase di sviluppo, test e controllo qualità, ma non in produzione. In realtà, se si tratta di un'applicazione per l'alimentazione di cani, ad esempio un'applicazione che usi tu stesso, dovresti anche averli attivati in produzione.

Fondamentalmente: averli attivati in quei casi in cui la persona che li vede è in grado di fare qualcosa su di loro (lo sviluppatore in fase di sviluppo e testing può correggerli da solo, il tester in QA può presentare un bug, e se lo sviluppatore è anche l'utente, quindi può anche correggerlo in produzione), ma non accenderli quando la persona che vede non può fare nulla su di loro (un utente in produzione, chi non sa nemmeno come programmare).

Idealmente, vorrai anche attivare gli avvertimenti come errori, ma funziona solo se non ce ne sono per cominciare ;-) Ma tienilo presente come obiettivo! Se è possibile attivare / disattivare questo file in base al file, attivarlo per tutti i nuovi file e attivarlo per tutti i file privi di avvertenze e non spegnerlo mai più una volta acceso.

Quindi, cosa fare per il sovraccarico?

Fai un elenco di ogni avviso e avviso, quindi aderisci alle seguenti regole:

1. Mai e poi mai aggiungere un nuovo avviso all'elenco. Ogni nuovo pezzo di codice, ogni modifica, ogni modifica, ogni patch, ogni commit non devono introdurre nuovi avvisi, può solo correggerli .
2. Ogni volta che tocchi un pezzo di codice, correggi tutti gli avvisi in quel pezzo di codice. (The Boyscout Rule: lascia sempre il campeggio in condizioni migliori di come l'hai trovato.) In questo modo, il codice non importante può rimanere pieno di avvertimenti, ma il codice importante diventerà più pulito nel tempo. "Pezzo di codice" può essere una funzione, una classe, un file. Puoi anche rilassare questa regola per dire di correggere almeno un avvertimento. Il punto è: aggiustali come li trovi.

Nota: entrambi richiedono una sorta di database di registro e meccanismo di filtraggio dei log. Nota anche che "log log" e "log filtering mechanism" potrebbero essere solo un file di testo e grep .

Questo è il bit importante. Senza il database, non saprai quando aggiungi un nuovo avviso e, senza il filtro, hai ancora il problema di sovraccarico.

Nota 2: questo non funziona solo per gli avvertimenti, ma funziona anche per i correttori di stile, le metriche di complessità, la copertura del codice, gli strumenti di analisi statica e così via. Fondamentalmente:

1. Non aggiungere nuovi problemi.
2. Risolvi i vecchi problemi mentre ti imbattuti in essi.

Questo ti permette di stabilire facilmente le priorità: il codice che viene modificato spesso e quindi deve essere facile da leggere e mantenere, migliorerà nel tempo. Il codice che non viene toccato spesso, non migliorerà, ma va bene, perché nessuno ha bisogno di guardarlo comunque. E , almeno non peggiorerà.

Naturalmente, nulla ti impedisce di allocare il tempo in modo specifico per non fare altro che dare la caccia e uccidere avvertimenti. È solo che spesso, questo non è economicamente sostenibile, ed è il tuo lavoro come ingegnere a tenerlo a mente. "Un ingegnere è uno che può costruire con un dollaro, quello che qualsiasi pazzo può costruire con due."

Se avvisi e avvisi provengono dal tuo codice, sicuramente risolverlo. Dalla mia esperienza, nel 95% potrebbe essere benigno, ma il 5% evidenzia un problema reale che può portare a innumerevoli ore trascorse a cacciare.

Se provengono dal codice di terze parti che devi utilizzare per un motivo o per l'altro, generalmente non hai molta scelta.

È una domanda diversa se la base di codice legacy è molto grande, quindi puoi trattare il codice precedente come di terze parti, ma richiedere che il nuovo codice sia privo di avvisi.

È importante. Un avvertimento potrebbe non interrompere i test o persino mostrarsi in natura per un po '- ma potrebbe essere un sintomo di un bug incombente. Attualmente mi sto sviluppando principalmente in C # / C ++ e ho una strategia definita per eliminare e tenere gli avvisi fuori dalla nostra base di codice. Fortunatamente non è scienza missilistica =).

Se la lingua in cui lavori ha la capacità di trattare gli avvertimenti come errori e ha livelli di avviso variabili, farei quanto segue:

1. Abbassa il livello di avviso abbastanza lontano da non ricevere avvisi. Se ti trovi al livello di avviso più basso e ricevi ancora avvertimenti, prova a risolverli. Se non riesci a risolverli, allora hai finito per ora, ma spero che possa correggerli. Grande.
2. Poiché ora non hai avvisi (molto probabilmente a un livello di avviso basso), attiva l'interruttore e considera tutti gli avvisi come errori.
3. Prova a alzare il livello di avviso e correggere tutti i nuovi avvisi. Se non è possibile, ripristinare il livello di avviso, ma non disattivare gli avvisi come errori.

Trovo che questo non solo funzioni gli avvisi fuori dal mio codice - li tiene fuori .