Come si esegue il debug senza un IDE? [chiuso]

Ogni volta che cerco un IDE (attualmente sto armeggiando con Go), trovo un thread pieno di persone che raccomandano Vi, Emacs, Notepad ++ ecc.

Non ho mai fatto alcun sviluppo al di fuori di un IDE; Immagino di essere stato viziato. Come si esegue il debug senza un IDE? Sei limitato alla sola registrazione?

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ù comunemente usati è GNU gdb, che ha ampiamente soppiantato i debugger Unix precedenti come dbx.

Per avere un'idea di come appare / si sente il debug dalla riga di comando, puoi consultare il manuale di gdb .

Come in altre aree, l'utilizzo di un debugger dalla riga di comando richiede l'apprendimento di una sintassi e un insieme di comandi, ma comporta molta flessibilità e gestibilità. D'altra parte, se ti senti già a tuo agio a lavorare 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 scrivevo driver grafici. Avevo un secondo computer che eseguiva il debugger contro il primo (perché lo schermo nel computer principale non funzionava quando il driver grafico era rotto). Era fondamentale riuscire a 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 sia molto più utile che passare attraverso il codice riga per riga. Con le dichiarazioni di stampa, ho un elenco di tutto ciò che è accaduto nella riga di comando o nel file di registro che posso guardare e ricostruire ciò che è accaduto, andando avanti e indietro più facilmente di quanto avrei mai potuto fare con un debugger.

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

Persone diverse hanno stili diversi e stili diversi sono migliori per compiti diversi. Le dichiarazioni di stampa non sono necessariamente un passo indietro rispetto a un debugger. A seconda di ciò che stai facendo, possono anche essere migliori. Soprattutto in una lingua che non ha un debugger nativo (Go?).

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

L'altro piccolo e sporco segreto degli IDE è che valgono tutti la pena: specificare un editor personalizzato, quindi è possibile utilizzare parti dell'IDE per determinate attività, ma utilizzare un editor decente per la modifica. Non è raro avviare un IDE solo per utilizzare il suo debugger, soprattutto se è quello che usano tutti i colleghi.

Alcune lingue offrono un REPL, ovvero 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 funzionalità di debug. 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 debug 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 tutto ciò che il programma ha fatto, 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 esadecimali, decimali, 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 indicazioni indirette. Puoi controllare l'output molto facilmente, mettere contatori, stampare solo determinate volte attraverso un ciclo, aggiungere e rimuovere istruzioni di stampa durante il debug, avere diversi livelli di output di debug, scrivere su file, ecc. È molto più facile vedere la cronologia del programma scritta su un file piuttosto che su prova a ricordare tutti i luoghi che hai attraversato manualmente e forse devi annotare il contenuto delle variabili mentre cambiano nel tempo, per scoprire cosa ha fatto il programma. E infine, con le istruzioni printf puoi lasciarle permanentemente, per essere accese e spente, per il debug futuro. è molto più facile vedere la cronologia del tuo programma scritta su un file piuttosto che cercare di ricordare tutti i luoghi che hai attraversato manualmente e forse dover scrivere il contenuto delle variabili mentre cambiano nel tempo, per scoprire cosa il programma ha fatto. E infine, con le istruzioni printf puoi lasciarle permanentemente, per essere accese e spente, per il debug futuro. è molto più facile vedere la cronologia del tuo programma scritta su un file piuttosto che cercare di ricordare tutti i luoghi che hai attraversato manualmente e forse dover scrivere il contenuto delle variabili mentre cambiano nel tempo, per scoprire cosa il programma ha fatto. E infine, con le istruzioni printf puoi lasciarle permanentemente, per essere accese e spente, per il debug futuro.

jimwise ha risposto abbastanza bene alla domanda, ma ho pensato di aggiungerlo, se dovessi scegliere di lavorare senza un IDE completo, il debugger della riga di comando fornito da Microsoft per Windows si chiama CDB . CDB viene fornito con molti altri strumenti, incluso WinDBG che è l'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 a cui vado.

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

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

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

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

Se hai sempre codificato usando la logica e la registrazione a livello di debug / traccia, può essere semplicemente il caso di esaminare le tue eccellenti dichiarazioni di registro (eventualmente aumentando il livello di registro) per capire il problema senza nemmeno accedere all'hardware.

Anche se penso che i debugger siano uno strumento potente, non lasciarli essere l'unico strumento nella tua cassetta degli attrezzi!

Non c'è motivo per cui non è possibile utilizzare il debugger in un IDE insieme a un editor di testo autonomo. Prima usavo! Zap per modificare, JBuilder per eseguire il debug su un'altra macchina e un file server nel seminterrato. Tradizionalmente i debugger erano programmi autonomi senza trascinare un IDE, e anche questo funziona.

Vale la pena notare che i test completi sostituiscono il debug. Vale la pena considerare un bug segnalato come un bug nei test piuttosto che nel codice.

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

Concordo sul fatto che i migliori problemi possano essere risolti dal computer con carta e penna o semplicemente pensando al problema. Questo è più utile dell'uso di debugger live. Corregge spesso il tuo processo di pensiero.

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 in modo più dettagliato.

Inoltre, controlla PythonDebuggingTools Wiki per una raccolta più completa di strumenti disponibili.