È buona norma evitare avvisi e avvisi?

In genere ho lavorato con avvisi e avvisi PHP, dato che lavoro a molti progetti in cui è già in produzione dal vivo. Ora, se accendo gli avvisi e gli avvisi su questi siti Web di produzione dal vivo, saranno sovraccarichi di essi.

I progetti su cui lavoro a casa, a livello locale, di solito cerco di eliminare TUTTI gli avvisi e le comunicazioni. A volte, non c'è soluzione per non avere un avviso, quindi dovrei solo occuparmi di guardare l'avviso fino a quando decido di spegnerli del tutto.

Alla fine, non so se sto sprecando il mio tempo cercando di sbarazzarmi di tutti gli avvisi e le comunicazioni, o che lo sto effettivamente facendo per il bene più grande.

Da qui la mia domanda, è una buona pratica evitare del tutto avvertimenti e avvisi o non importa davvero?

php warnings

— Audite Marlow
fonte

"A volte, non c'è soluzione per non avere un avviso" È passato un po 'di tempo da quando ho usato PHP, ma non ricordo di essermi imbattuto in un caso in cui potresti evitare l'avviso / avviso o almeno sopprimerlo localmente@ .

— CodesInCos

L'argomento più convincente che ho visto è che "quei messaggi esistono per una ragione: condizionarci per ignorare un flusso di avvertimenti ci fa trascurare i problemi reali che potrebbero essere stati evitati". In altre parole, se non ci sono avvisi o avvisi durante le normali operazioni, qualsiasi avviso o avviso è un segnale di potenziale problema; se tutto è solo rumore, inizierai a notare problemi solo dopo SHTF (e probabilmente dopo che i clienti lo fanno).

— Piskvor,

L'uso di @ per sopprimere gli avvisi, sebbene comune, è generalmente considerato una cosa negativa. È peggio che semplicemente disattivare tutte le notifiche perché ora hai nascosto un potenziale problema. In 15 anni di programmazione php devo ancora imbattermi in un caso in cui ho dovuto sopprimere un avviso nel codice che controllo.

— Cerad,

Stai semplicemente disattivando la visualizzazione di questi avvisi o lo stai facendo error_reporting(0);? Io uso sempre error_reporting(E_ALL);e l'unica differenza tra lo sviluppo e la produzione è ini_set('display_errors', 'on');vs ini_set('display_errors', 'off');. Ho sempre l'obiettivo di correggere avvisi e avvisi mentre il codice è ancora fresco nella mia mente. Frequento i registri sul mio sistema di produzione per vedere se ci sono ulteriori avvertenze e avvisi che potrei aver perso.

— MonkeyZeus,

Sono molto d'accordo con quello che ha detto @Cerad @. Dopo anni e anni di programmazione PHP, non ho usato quell'operatore. Non una volta. Mai. Non solo nasconde potenziali problemi, ma ha anche un impatto sulle prestazioni: dietro le quinte, PHP disattiva la segnalazione degli errori prima di chiamare il codice -> chiama il codice -> ripristina il valore originale. Questi passaggi sono costosi se ne hai dozzine o centinaia @nel tuo codice.

— Radu Murzea,

Risposte:

se accendo gli avvisi e le comunicazioni su questi siti Web di produzione live, saranno sovraccarichi di essi.

Dovresti sempre avere gli avvisi attivati al massimo livello nello sviluppo, nei test e nel QA, ma non nella produzione. In realtà, se si tratta di un'applicazione dogfooding, cioè un'applicazione che usi te stesso, allora dovresti anche averli accesi in produzione.

Fondamentalmente: attivali nei casi in cui la persona che li vede è in grado di fare qualcosa al riguardo (lo sviluppatore in fase di sviluppo e test può risolverli da solo, il tester in QA può presentare un bug e se lo sviluppatore è anche l'utente, quindi può anche risolverlo in produzione), ma non accenderlo quando la persona che vede non può farci nulla (un utente in produzione, che non sa nemmeno come programmare).

Idealmente, vorrai anche attivare il trattamento degli avvisi come errori, ma funziona solo se non ce ne sono per cominciare ;-) Ma tienilo a mente come obiettivo! Se è possibile attivarlo / disattivarlo in base al file, accenderlo per tutti i nuovi file, accenderlo per tutti i file privi di avvisi e non spegnerlo mai più una volta acceso.

Quindi, cosa fare per il sovraccarico?

Fai un elenco di tutti gli avvisi e gli avvisi, quindi segui le seguenti regole:

Mai e poi mai, in nessun caso aggiungere un nuovo avviso all'elenco. Ogni nuovo pezzo di codice, ogni modifica, ogni modifica, ogni patch, ogni commit non deve introdurre nuovi avvisi, può solo risolverli .
Ogni volta che tocchi un pezzo di codice, correggi tutti gli avvisi in quel pezzo di codice. (La regola di Boyscout: lascia sempre il campeggio in condizioni migliori di quelle che 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 avviso. Il punto è: correggili quando li trovi.

Nota: entrambi richiedono la presenza di una sorta di database dei registri e meccanismo di filtraggio dei registri. Si noti inoltre che "database di registro" e "meccanismo di filtraggio dei registri" potrebbero essere solo un file di testo e grep.

Questa è la parte importante. Senza il database, non si saprà quando si aggiunge un nuovo avviso e senza il filtro si avrà ancora il problema di sovraccarico.

Nota n. 2: questo non funziona solo per gli avvisi, ma funziona anche per verificatori di stile, metriche di complessità, copertura del codice, strumenti di analisi statica e così via. Fondamentalmente:

Non aggiungere nuovi problemi.
Risolvi i vecchi problemi mentre ti imbatti in loro.

Ciò consente 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 deve guardarlo comunque. E almeno non peggiorerà.

Naturalmente, nulla ti impedisce di allocare tempo in modo specifico per non fare altro che cacciare e uccidere gli avvisi. È solo che spesso, questo non è economicamente praticabile, ed è il tuo lavoro come ingegnere a tenerlo presente. "Un ingegnere è colui che può costruire con un dollaro, ciò che qualsiasi sciocco può costruire con due."

— Jörg W Mittag
fonte

Un altro punto per cui disattivare gli avvisi e gli errori che raggiungono l'utente non filtrato: per quanto informativo sia un avvertimento per lo sviluppatore, potrebbe perdere informazioni sensibili (nomi di file, nomi di altri server coinvolti, struttura delle query sql utilizzate, ... )

— Hagen von Eitzen del

Gli avvertimenti in produzione dovrebbero andare nei registri, non all'utente! Gli errori dovrebbero andare nei registri, non all'utente. Un sito Web che non intercetta errori, li registra e pubblica una pagina di errore adatta all'utente, invece non è pronto per la produzione. PHP rende molto semplice fare questo male, ma dovresti comunque farlo nel modo giusto.

— Hobbs

Se avvertimenti e avvisi provengono dal tuo codice, sicuramente risolvilo. In base alla mia esperienza, nel 95% può essere benigno, ma il 5% evidenzia un problema reale che può portare a innumerevoli ore trascorse all'inseguimento.

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

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

— Alexander Pogrebnyak
fonte

Lavoro in Java / eclipse, che ovviamente è diverso da php, ma di solito trovo che l'avvertimento sia sollevato da 1) qualcosa che si compila ma ho fatto un ovvio errore o 2) qualcosa che ora va bene ma andrà male lungo la strada

— corsiKa

@corsiKa Mi stavo traducendo il tuo commento e PHP, ma mi sono reso conto che una sola parola aveva bisogno di essere cambiato.

— wizzwizz4,

A meno che, naturalmente, questi avvertimenti non vengano da StyleCop sul tuo ordine delle tue usingdichiarazioni ...

— Dan Pantry,

Importa. Un avviso potrebbe non interrompere i test o persino presentarsi allo stato brado per un po ', ma potrebbe essere un sintomo di un bug incombente. Attualmente sviluppo 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 avvisi come errori e ha livelli di avviso variabili, farei quanto segue:

Abbassa il livello di avviso abbastanza lontano da non ricevere alcun avviso. Se sei al livello di avviso più basso e ricevi ancora avvisi, prova a risolverli. Se non riesci a risolverli, allora hai finito per ora, ma spero che tu possa risolverli. Grande.
Dato che ora non hai avvisi (molto probabilmente con un livello di avviso basso), gira l'interruttore e tratta tutti gli avvisi come errori.
Cerca di alzare il livello di avviso e correggere tutti i nuovi avvisi. Se non ci riesci, riduci il livello di avviso, ma non disattivare tratta gli avvisi come errori.

Trovo che questo non solo funzioni avvertimenti dal mio codice, ma li tiene fuori .

— PerryC
fonte