Come si esegue il debug senza IDE? [chiuso]

Usando un debugger. Per la maggior parte, questo è anche ciò che fa un IDE dietro le quinte: avvolge semplicemente l'esperienza in una GUI.

Su Unix, uno dei debugger più usati è GNU gdb , che ha ampiamente soppiantato i precedenti debug di Unix come dbx .

Per avere un'idea di cosa assomiglia / sembra il debugging dalla riga di comando, puoi consultare il manuale gdb .

Come in altre aree, l'uso di un debugger dalla riga di comando richiede l'apprendimento di una sintassi e di un insieme di comandi, ma porta con sé un lotto di flessibilità e scriptability. D'altra parte, se sei già a tuo agio lavorando in un editor come vim o emacs, potresti scoprire che il tuo editor preferito ha un plug-in per il tuo debugger preferito.

Ho usato un debugger per diversi anni mentre stavo scrivendo i driver grafici. Avevo un secondo computer che eseguiva il debugger contro il primo (perché lo schermo del computer principale non funzionava quando il driver grafico era rotto). È stato fondamentale poter fermare il codice e passare al punto in cui ho appeso l'hardware in modo da sapere cosa stava succedendo.

Per problemi puramente software, trovo che pensare al problema e testare il sistema per saperne di più sul problema è molto più utile che passare attraverso il codice riga per riga. Con le istruzioni di stampa, ho un elenco di tutto ciò che è accaduto alla riga di comando o del file di registro che posso guardare e ricostruire quello che è successo, andando avanti e indietro più facilmente di quanto possa mai con un debugger.

Solitamente i bug più difficili vengono risolti comprendendo il problema dal computer. A volte con un pezzo di carta o una lavagna, ea volte la risposta si rivela mentre sto facendo qualcos'altro. I bug più difficili vengono risolti guardando attentamente il codice come se stessi giocando a Where's Waldo. Tutto il resto sembra più semplice con le dichiarazioni di stampa o le dichiarazioni di registrazione.

Diverse persone hanno stili diversi e stili diversi sono migliori per compiti diversi. Le dichiarazioni di stampa non sono necessariamente un passo indietro da un debugger. A seconda di ciò che stai facendo, possono anche essere migliori. Soprattutto in un linguaggio che non ha un debugger nativo (va?).

Alcune persone usano gdb sulla riga di comando o plugin . Ci sono anche front-end GUI standalone per gdb, come DDD . A seconda della lingua, ci sono GUI standalone debugger specifiche della lingua, come Winpdb per python, o jswat per java. Poiché questi progetti focalizzano solo sul debug, sono spesso superiori ai debugger integrati.

L'altro piccolo e sporco segreto sugli IDE è tutto ciò che vale la pena, permettici di specificare un editor personalizzato, quindi puoi usare parti dell'IDE per determinate attività, ma usa un editor decente per la modifica. Non è raro che accenda un IDE solo per usare il suo debugger, specialmente se è quello che usano tutti i colleghi.

Alcune lingue offrono un REPL - cioè, puoi scrivere ed eseguire il codice riga per riga mentre lo scrivi, che può essere un primo passo per verificare un pezzo di codice. Molti di questi offrono anche servizi di debugging. GHC per Haskell viene fornito con GHCi che può essere utilizzato per eseguire il debug interattivo di un programma nella riga di comando, in modo simile a come farebbe un IDE.

Non capisco perché ci sia un'avversione al debugging con l'uso delle istruzioni printf. C'è stato un tempo in cui ci è voluto troppo tempo per ricompilare e collegare un programma, ma oggi ci vogliono solo pochi secondi. Trovo molto facile eseguire il debug usando il tipo di output cout, printf, qDebug (), ecc. Le istruzioni Printf forniscono una cronologia di tutte le operazioni eseguite dal programma, che è possibile analizzare dopo il fatto, mentre l'esecuzione nel debugger comporta la necessità di ricordare manualmente il flusso del programma durante l'esecuzione. Con printf, puoi convertire il valore delle variabili in unità specifiche, visualizzarle in esadecimale, decimale, qualunque cosa. Le istruzioni printf possono elencare i nomi delle routine e delle variabili e anche i numeri di riga. È possibile elencare solo determinati elementi dell'array in base ad altre variabili. Puoi seguire le indecisioni. È possibile controllare l'output molto facilmente, inserire contatori, stampare determinate volte attraverso un ciclo, aggiungere e rimuovere le istruzioni di stampa durante il debug, avere diversi livelli di output di debug, scrivere su file, ecc. È molto più facile vedere la cronologia di il tuo programma scritto su un file piuttosto che cercare di ricordare tutti i luoghi che hai passato manualmente, e magari dover scrivere il contenuto delle variabili mentre cambiano nel tempo, per scoprire cosa ha fatto il programma. Infine, con le istruzioni printf puoi lasciarle permanentemente, per essere attivate e disattivate, per il debugging futuro.

jimwise ha risposto alla domanda abbastanza bene, ma ho pensato che dovrei aggiungere che, dovrebbe si sceglie di lavorare senza un IDE completo, il debugger della riga di comando fornito da Microsoft per Windows è chiamato CDB . CDB include molti altri strumenti, tra cui WinDBG che è il Equivalente della GUI, quando si scarica Windows SDK.

Di solito non uso un debugger, forse una volta ogni due settimane ma non è la prima cosa che vado a fare.

Lo strumento più importante del mio lavoro è così onnipresente che ho quasi dimenticato di menzionarlo - tracce di stack. Oltre il 90% dei problemi che ho incontrato può essere risolto esaminando una traccia dello stack. Questo strumento non è sempre molto utile a seconda della lingua, ma quando vengono implementati bene da una lingua possono farti risparmiare una quantità incredibile di tempo.

Credo che il secondo modo più comune in cui rilevo problemi semplici è che probabilmente è il codice che ho appena cambiato. Eseguo test unitari abbastanza spesso, quindi generalmente so cosa ho appena rotto.

Per uno sviluppo e un debug più complesso, potrei aggiungere alcune istruzioni di registro di livello di debug o traccia. Considero i problemi di sviluppo una buona guida per aiutarmi a inserire le informazioni di registrazione traccia / debug di produzione, il che mi porta a:

Non hai sempre un debugger a portata di mano. In produzione potrebbe essere impossibile eseguire un debugger (Heck, potrebbe essere impossibile accedere alle macchine di produzione ad eccezione dei registri a seconda della sicurezza della tua azienda). Ci sono anche lingue in cui il collegamento di un debugger richiede troppo tempo o forse non ci sono solo debugger disponibili.

Se si è sempre stato codificato utilizzando la registrazione logica e di livello debug / trace, può essere semplicemente il caso di esaminare le eccellenti dichiarazioni del registro (Possibilmente aumentando il livello del registro) per capire il problema senza nemmeno accedere all'hardware.

Anche se penso che i debugger siano uno strumento potente, non lasciare che siano l'unico strumento nella tua casella degli strumenti!

Non c'è motivo per cui non puoi usare il debugger in un IDE insieme a un editor di testo autonomo. Ho usato per usare! Zap per modificare, JBuilder per eseguire il debug su un'altra macchina e un fileserver nel seminterrato. Tradizionalmente i debugger erano programmi standalone senza trascinare lungo un IDE e anche questo funziona.

Vale la pena notare che il test completo sostituisce il debug. Vale la pena considerare un bug segnalato come un bug nel test piuttosto che nel codice.

C'è anche printf . Può essere utile creare una grande quantità di "logging" e cercare attraverso di essa, piuttosto che fermarsi per ogni linea. Trovo particolarmente utile se è possibile modificare le classi di libreria che non sarebbe possibile modificare in produzione, ad esempio utilizzando -Xbootclasspath/p: per modificare le classi di librerie Java.

Accorda che i migliori problemi possono essere risolti via dal computer con carta e penna o semplicemente pensando al problema. Questo è più utile rispetto all'utilizzo di debugger dal vivo. Corregge spesso il tuo modo di pensare.

Puoi usare pudb che è una console basata su una semplice interfaccia utente. Puoi scegliere il tuo debugger preferito come pdb o ipdb se vuoi inserire un REPL ed esaminare più in dettaglio.

Controlla anche PythonDebuggingTools Wiki per una raccolta più completa di strumenti disponibili.