Per esempio, aggiungo solo il codice di debug (come le istruzioni di stampa) quando sto cercando di individuare un bug. E una volta trovato, rimuovo il codice di debug (e aggiungo un caso di test che verifica specificamente quel bug). Sento che sta ingombrando il vero codice e quindi non ha spazio lì a meno che non stia eseguendo il debug.
Come si fa? Lasci il codice di debug in atto o lo rimuovi quando è obsoleto (che può essere difficile giudicare quando lo è)?
Risposte:
È necessario eliminare le dichiarazioni di stampa di debug; tuttavia, se è necessario aggiungerli per eseguire il debug di un problema di produzione, potrebbe valere la pena considerare se si dispone di informazioni sufficienti da inserire nel framework di registrazione. Informazioni su parametri, condizioni di errore e così via potrebbero essere utili in seguito quando viene visualizzato il bug successivo. L'utilizzo di un buon framework di registrazione in cui è possibile attivare il debug o la traccia dinamica dei messaggi di registro può essere molto utile in natura.
Il codice aggiunto specificamente per il debug deve essere rimosso dal software di produzione.
Che si tratti di rimozione completa o di essere inserito in sezioni di compilazione condizionale (come in C / C ++ / C #) dipende da te e dal tuo standard di codifica.
Ci sono diverse ragioni per questo:
ChrisF e Alaric hanno entrambi punti validi; +1 per loro. Sono in grado di identificare almeno 5 diversi tipi di codice di debug che utilizzo.
Utilizzo dei log per scaricare lo stato del sistema in un determinato momento.
void function(...)
{
...dump everything i know about.
}
Utilizzo dei registri per i punti di controllo dell'esecuzione.
void function(...)
{
...got here 1
...got here 2
}
Codice che impone effettivamente che una determinata condizione sia vera, ma rompe il comportamento normale. Esempio:
Registrazione di verifica: classificherei questo come una registrazione dettagliata che può essere utilizzata per convalidare la correttezza del software che non dovrebbe essere inclusa nella produzione, come ad esempio la convalida dei singoli passaggi di un algoritmo.
Registrazione operazioni: fare riferimento al post di Alaric . Questo è praticamente ciò che intendo per "registrazione delle operazioni".
1, 2 e 3 dovrebbero essere eliminati completamente. Qualcosa come 4 probabilmente compilerei in modo condizionale dal codice. Per 5, Alaric ha avuto un grande punto sulla possibilità di disattivare dinamicamente i log. Questo potrebbe affrontare il punto di ChrisF nel suo secondo proiettile nella maggior parte dei casi.
1)... con 1.... (in modo che la formattazione Markdown lo raccolga come un elenco) e indentando il codice di esempio di 8 spazi (di nuovo, in modo che Markdown lo raccolga come esempio codice all'interno di un elenco).
Dipende da cosa sta facendo il codice. Alcuni codici utilizzati per il debug possono essere lasciati così come sono e alcuni devono essere rimossi.
Il codice che verifica l'integrità dei parametri in un metodo non è sempre utile quando il codice funziona correttamente, ma spesso viene mantenuto per assicurarsi che il codice continui a funzionare correttamente.
A volte si scrive codice in modo diverso per semplificare il debug del codice, ad esempio calcolando un valore e inserendolo in una variabile locale, quindi si utilizza la variabile nella riga successiva, il che semplifica il controllo del risultato del calcolo quando si passa da un passo all'altro attraverso il codice. È possibile riscrivere il codice per utilizzare direttamente il valore calcolato, ma il costo dell'uso della variabile locale è così piccolo (se non del tutto) che non vi è motivo di riscrivere il codice. Inoltre, è utile lasciare invariato il codice dopo averlo testato, c'è sempre un piccolo rischio di introdurre un bug quando lo si modifica.
Il codice che aggiungi solo per rintracciare un bug specifico può spesso essere rimosso dopo aver trovato il bug.
Una volta utilizzavo molto codice di debug. Stavo quasi interamente prendendo di mira Windows, quindi c'era molto di questa funzione di output della stringa di debug che non ricordo più come si scrive, in modo da poter catturare la traccia con un particolare programma.
Rimaneva al suo posto un codice di debug, cose particolari che avevano lo scopo di fornire l'annidamento delle chiamate. Tuttavia, anche se la cosa della stringa di debug per lo più non sarebbe visibile su un sistema di produzione, era ancora tutto fatto sotto compilazione condizionale.
La realtà è, tuttavia, che tutto quel codice di debug è stato un grande sforzo per qualcosa che è idealmente gestito in un modo diverso - usando, ovviamente, un debugger. All'epoca, non ero così colpito dal debugger C ++ di Borland. Gli strumenti erano lì, ma troppo spesso davano risultati fuorvianti e l'uso del debugger non IDE (spesso necessario) significava memorizzare i tasti di scelta rapida, il che significava una distrazione dal lavoro da svolgere.
L'unica esperienza di debug che ho trovato che è peggio è GDB da riga di comando.
Essere un esperto con gli strumenti che usi ogni giorno è, ovviamente, importante - ma il debug non dovrebbe essere qualcosa che fai ogni giorno. Se usi il debugger così spesso stai bene con l'apprendimento di dozzine di comandi e / o scorciatoie da tastiera, mi sembra un po 'bandiera rossa.
Quando lavoravo in Visual Studio 7, tuttavia, era chiaro che il debug poteva essere molto pratico ed efficace. Se riesci a eseguire il debug in Visual Studio (incluse le versioni express), il debug è semplicissimo. Senza dubbio se riesci a trovare il front end GUI / IDE giusto, GDB è anche semplice ed efficace, anche se non ho ancora fatto quella ricerca.
C'è anche qualcosa da dire per i test unitari, con l'analisi della copertura usando gcov. Più sei sicuro del comportamento delle tue librerie, meno profondo deve essere il tuo debug - e meno spesso hai bisogno del debugger. E scrivere unit test è abbastanza ragionevole da fare quasi tutti i giorni.
Tool inaspettatamente importante = cmake, uno strumento di compilazione che mi consente di passare facilmente da un edificio all'altro per GCC e VC ++, tra le altre cose. Quindi posso fare i test delle mie unità e la copertura basata su gcov usando GCC, ma passare facilmente a VC ++ per usare il debugger.
La mia opinione su di esso: il codice di debug utilizzato per uccidere un bug all'interno del codice in questione che generalmente rimuovo completamente. Il codice di debug utilizzato per uccidere un bug derivante da forze esterne in genere semplicemente commento.
Se il bug proviene dall'unità test o dall'interno, il codice di debug potrebbe essere rimosso del tutto. Ma se il bug proviene dalla produzione, è meglio che il codice di debug sia presente all'interno dei tag di compilazione. Metterlo all'interno dei tag di compilazione aiuterà gli altri sviluppatori a capire che questo codice è solo a scopo di debug.
Usa TDD , quindi il tuo codice di prova ha sempre un posto dove viene persino mantenuto.