Perché il debug è migliore in un IDE? [chiuso]

Sono uno sviluppatore software da oltre vent'anni, programmando in C, Perl, SQL, Java, PHP, JavaScript e recentemente Python. Non ho mai avuto problemi a cui non ho potuto eseguire il debug con un pensiero attento e printdichiarazioni di debug ben posizionate .

Rispetto che molte persone affermano che le mie tecniche sono primitive e che usare un vero debugger in un IDE è molto meglio. Tuttavia, dalla mia osservazione, gli utenti IDE non sembrano eseguire il debug più velocemente o con più successo di me, usando i miei coltelli di pietra e le pelli dell'orso. Sono sinceramente aperto all'apprendimento degli strumenti giusti, non mi è mai stato mostrato un avvincente vantaggio nell'uso dei debugger visivi.

Inoltre, non ho mai letto un tutorial o un libro che mostrasse come eseguire il debug in modo efficace utilizzando un IDE, al di là delle basi su come impostare i punti di interruzione e visualizzare il contenuto delle variabili.

Cosa mi sto perdendo? Cosa rende gli strumenti di debug IDE molto più efficaci dell'uso ponderato delle printdichiarazioni diagnostiche ?

Puoi suggerire risorse (tutorial, libri, screencast) che mostrano le tecniche più fini di debug IDE?

Dolci risposte! Grazie mille a tutti per aver dedicato del tempo. Molto illuminante Ho votato a favore di molti e nessuno ha votato a favore.

Alcuni punti notevoli:

• I debugger possono aiutarmi a eseguire ispezioni o modifiche ad hoc di variabili, codice o qualsiasi altro aspetto dell'ambiente di runtime, mentre il debug manuale richiede di interrompere, modificare e rieseguire l'applicazione (eventualmente richiedendo la ricompilazione).
• I debugger possono collegarsi a un processo in esecuzione o utilizzare un dump di arresto anomalo, mentre con il debug manuale sono necessari "passaggi per riprodurre" un difetto.
• I debugger possono visualizzare strutture dati complesse, ambienti multi-thread o stack di runtime completi facilmente e in modo più leggibile.
• I debugger offrono molti modi per ridurre il tempo e il lavoro ripetitivo per eseguire quasi tutte le attività di debug.
• Debugger visivi e debugger della console sono entrambi utili e hanno molte caratteristiche in comune.
• Un debugger visivo integrato in un IDE offre anche un comodo accesso alla modifica intelligente e a tutte le altre funzionalità dell'IDE, in un unico ambiente di sviluppo integrato (da cui il nome).

Alcuni esempi di alcune abilità che un debugger IDE ti darà sui messaggi di traccia nel codice:

• Visualizza lo stack di chiamate in qualsiasi momento, offrendo un contesto per il tuo frame di stack corrente.
• Passa alle librerie che non riesci a ricompilare allo scopo di aggiungere tracce (supponendo che tu abbia accesso ai simboli di debug)
• Modifica i valori delle variabili mentre il programma è in esecuzione
• Modifica e continua: la possibilità di modificare il codice mentre è in esecuzione e vedere immediatamente i risultati della modifica
• Essere in grado di guardare le variabili, vedendo quando cambiano
• Essere in grado di saltare o ripetere sezioni di codice , per vedere come si esibirà il codice. Ciò consente di testare le modifiche teoriche prima di apportarle.
• Esamina i contenuti della memoria in tempo reale
• Ti avvisa quando vengono generate determinate eccezioni , anche se gestite dall'applicazione.
• Breakpoint condizionale ; arrestare l'applicazione solo in circostanze eccezionali per consentire di analizzare lo stack e le variabili.
• Visualizza il contesto del thread in applicazioni multi-thread, che può essere difficile da ottenere con la traccia (poiché le tracce di thread diversi verranno interfogliate nell'output).

In breve, le dichiarazioni di stampa sono (generalmente) statiche e dovrai ricompilare per ottenere informazioni aggiuntive se le tue dichiarazioni originali non erano abbastanza dettagliate. L'IDE rimuove questa barriera statica, dandoti un toolkit dinamico a portata di mano.

Quando ho iniziato a scrivere codice, non riuscivo a capire quale fosse il grosso problema con i debugger e pensavo di poter ottenere qualsiasi cosa con la traccia (garantito, che era su unix e il debugger era GDB). Ma una volta che hai imparato come usare correttamente un debugger grafico, non vuoi tornare alle dichiarazioni di stampa.

• Un debugger IDE consente di modificare i valori delle variabili in fase di esecuzione.

• Un debugger IDE ti consente di vedere il valore di variabili che non sapevi di voler vedere all'inizio dell'esecuzione.

• Un debugger IDE ti consente di vedere lo stack di chiamate ed esaminare lo stato della funzione passato valori strani. (pensa che questa funzione sia chiamata da centinaia di luoghi, non sai da dove provengano questi strani valori)

• Un debugger IDE consente di interrompere in modo condizionale l'esecuzione in qualsiasi punto del codice, in base a una condizione, non a un numero di riga.

• Un debugger IDE ti consentirà di esaminare lo stato del programma nel caso di un'eccezione non gestita anziché semplicemente saltar fuori.

Ecco una cosa che sicuramente non puoi eseguire il debug con l'istruzione "print", che è quando un cliente ti porta il dump della memoria e dice "il tuo programma è andato in crash, puoi dirmi perché?"

• Stampare le dichiarazioni in tutto il codice riduce la leggibilità.
• L'aggiunta e la rimozione solo a scopo di debug richiede tempo
• I debugger tengono traccia dello stack di chiamate rendendo più facile vedere dove ti trovi
• Le variabili possono essere modificate al volo
• I comandi ad hoc possono essere eseguiti durante una pausa nell'esecuzione per facilitare la diagnosi
• Può essere utilizzato IN CONGIUNZIONE con le istruzioni di stampa: Debug.Write ("...")

Penso che il debug utilizzando le dichiarazioni di stampa sia un'arte perduta e molto importante per ogni sviluppatore da imparare. Una volta che sai come farlo, alcune classi di bug diventano molto più facili da eseguire il debug in quel modo che attraverso un IDE. I programmatori che conoscono questa tecnica hanno anche una buona idea di quali informazioni utili inserire in un messaggio di registro (per non dire che finirai per leggere il registro) anche per scopi non di debug.

Detto questo, dovresti davvero sapere come utilizzare il debugger step-through, poiché per una diversa classe di bug è MODO più semplice. Lascio alle altre eccellenti risposte già pubblicate per spiegare perché :)

In cima alla mia testa:

1. Debug di oggetti complessi : i debugger ti consentono di entrare in profondità nelle viscere di un oggetto. Se il tuo oggetto ha, per esempio, una matrice di array di oggetti complessi, le istruzioni di stampa ti porteranno solo lontano.
2. Possibilità di superare il codice : i debugger ti consentiranno anche di saltare il codice che non desideri eseguire. È vero, potresti farlo anche manualmente, ma è molto più codice che devi iniettare.

In alternativa al debug in IDE puoi provare la fantastica console PHP con estensione Google Chrome con libreria php che ti permette di:

• Visualizza errori ed eccezioni nella console JavaScript di Chrome e nei popup di notifica.
• Scarica qualsiasi variabile di tipo.
• Esegui il codice PHP in remoto.
• Proteggi l'accesso tramite password.
• Raggruppa i log della console su richiesta.
• Vai al file di errore: riga nell'editor di testo.
• Copia i dati di errore / debug negli Appunti (per tester).

Non sviluppo da quasi 20 anni, ma trovo che usando un IDE / debugger posso:

• vedere tutti i tipi di cose che potrei non aver pensato di aver incluso in una dichiarazione stampata
• scorrere il codice per vedere se corrisponde al percorso che pensavo avrebbe preso
• imposta le variabili su determinati valori per fare in modo che il codice prenda determinati rami

Un motivo per utilizzare l'IDE potrebbe essere che gli IDE moderni supportano più di semplici punti di interruzione. Ad esempio, Visual Studio offre le seguenti funzionalità di debug avanzate:

• definire i punti di interruzione condizionali (interruzione solo se viene soddisfatta una condizione o solo all'ennesima volta viene eseguita l'istruzione al punto di interruzione)
• interrompere un'eccezione non gestita o ogni volta che deve essere generata un'eccezione (specifica)
• cambia variabile durante il debug
• ripetendo un pezzo di codice impostando la riga successiva da eseguire
• eccetera.

Inoltre, quando si utilizza il debugger, non sarà necessario rimuovere tutte le dichiarazioni di stampa al termine del debug.

Una cosa che sono sorpresa di non aver visto in un'altra risposta è che i 2 metodi di debug non si escludono a vicenda .

printfil debug può funzionare abbastanza bene anche se si utilizza un debugger standard (basato su IDE o meno). In particolare con un framework di registrazione in modo da poter lasciare tutto o la maggior parte del prodotto rilasciato per aiutare a diagnosticare i problemi dei clienti.

Come notato praticamente in tutte le altre risposte qui, la cosa bella chiave di un debugger standard è che ti permette di esaminare più facilmente (e potenzialmente modificare) i dettagli dello stato del programma. Non devi sapere in anticipo cosa potresti voler guardare: è tutto a portata di mano (più o meno).

Nella mia esperienza, le stampe semplici hanno un enorme vantaggio che nessuno sembra menzionare.

Il problema con un debugger IDE è che tutto accade in tempo reale. Interrompi il programma in un determinato momento, quindi esegui i passaggi uno alla volta ed è impossibile tornare indietro se improvvisamente vuoi vedere cosa è successo prima. Questo è completamente in contrasto con il funzionamento del nostro cervello. Il cervello raccoglie informazioni e forma gradualmente un'opposizione. Potrebbe essere necessario ripetere più volte gli eventi nel farlo, ma una volta superato un certo punto, non è possibile tornare indietro.

Al contrario, una serie selezionata di stampe / registrazioni offre una "proiezione spaziale degli eventi temporali". Ti dà una storia completa di ciò che è accaduto e puoi tornare indietro e quarto più volte molto facilmente semplicemente scorrendo su e giù. Rende facile rispondere a domande come "si è verificato A prima che si verificasse B". Può farti vedere modelli che non stavi nemmeno cercando.

Quindi nella mia esperienza. IDE e debugger sono strumenti fantastici per risolvere semplici problemi quando qualcosa in un singolo stack di chiamate è andato storto ed esplorare lo stato attuale della macchina in un certo arresto.

Tuttavia, quando ci avviciniamo a problemi più difficili in cui è coinvolto il cambiamento graduale di stato. Laddove ad esempio un algoritmo ha danneggiato una struttura di dati, ciò a sua volta ha provocato il fallimento di un altro algoritmo. O se vogliamo rispondere a domande come "quanto spesso succede", "le cose accadono nell'ordine e nel modo in cui immagino che accadano". ecc. Quindi la tecnica di registrazione / stampa "vecchio stile" presenta un chiaro vantaggio.

La cosa migliore è utilizzare una delle tecniche quando è più adatta, ad esempio utilizzare la registrazione / stampe per ottenere alcuni bug e fare una pausa in un punto di interruzione in cui è necessario esplorare lo stato corrente in modo più dettagliato.

Esistono anche approcci ibridi. Ad esempio, quando si esegue console.log (oggetto) si ottiene un widget della struttura dei dati nel registro che è possibile espandere ed esplorare più in dettaglio. Questo è molte volte un chiaro vantaggio rispetto a un registro di testo "morto".

Perché il debug di applicazioni multi-thread con istruzioni di stampa ti guiderà banane. Sì, puoi ancora farlo con le istruzioni di stampa, ma ne avresti bisogno molte e svelare la stampa sequenziale delle istruzioni per emulare l'esecuzione multi-thread richiederebbe molto tempo.

Sfortunatamente, i cervelli umani sono solo a thread singolo.

Dal momento che hai chiesto indicazioni ai libri ... Per quanto riguarda il debug di Windows, John Robbins ha diverse edizioni di un buon libro sul debug di Windows:

Debug di applicazioni per Microsoft .NET e Microsoft Windows

Nota che l'edizione più recente ( debug di applicazioni Microsoft .NET 2.0 ) è solo .NET, quindi potresti volerne una più vecchia (come nel primo link) se vuoi il debug del codice nativo (copre sia .NET che nativo).

Personalmente ritengo che la risposta sia semplice come "Un debugger / IDE integrato ti fornisce una vasta gamma di informazioni diverse rapidamente senza la necessità di digitare i comandi. Le informazioni tendono ad essere lì di fronte a te senza che tu non abbia detto cosa mostrarti.

La facilità con cui è possibile recuperare le informazioni è ciò che le rende migliori del semplice debug da riga di comando o del debug "printf".

Vantaggi di un debugger rispetto a un printf ( notare non un debugger IDE ma qualsiasi debugger )

1. Può impostare punti di controllo. Questo è uno dei miei modi preferiti per trovare danni alla memoria

2. Può eseguire il debug di un file binario che al momento non è possibile ricompilare

3. Può eseguire il debug di un file binario che richiede molto tempo per ricompilarsi

4. Può cambiare le variabili al volo

5. Può chiamare funzioni al volo

6. Non ha il problema in cui i statemenet di debug non vengono scaricati e quindi il problema di temporizzazione non può essere eseguito correttamente il debug

7. I debugger aiutano con i core dump, le dichiarazioni di stampa non '

Questo è quello che uso di più nelle finestre di debug VS.NET:

• Call stack, che è anche un ottimo modo per capire il codice di qualcun altro
• Locali e orologi.
• Finestra immediata, che è fondamentalmente una console C # e mi permette anche di cambiare contenuto variabile, inizializzare cose ecc.
• La possibilità di saltare una riga, imposta la prossima istruzione da eseguire altrove.
• La capacità di passare il mouse sopra le variabili e avere una descrizione che mi mostra i loro valori.

In sintesi, mi dà una visione a 360 gradi dello stato del mio codice di esecuzione, non solo una piccola finestra.

Non ho mai trovato un libro che insegna questo genere di cose, ma poi, sembra essere abbastanza semplice, è praticamente WYSIWYG.

• Un debugger può collegarsi a un processo in esecuzione

• Spesso è più facile eseguire il debug del codice thread da un debugger

Con un debugger IDE è possibile visualizzare i valori di TUTTE le variabili nell'ambito corrente (fino allo stack di chiamate) ogni volta che si interrompe l'esecuzione.

Le dichiarazioni di stampa possono essere fantastiche, ma scaricare così tante informazioni sullo schermo in un determinato posto può produrre un tutto sacco di dichiarazioni di stampa.

Inoltre, molti debugger IDE ti consentono di digitare e valutare i metodi e valutare i membri mentre sei fermo, il che aumenta ulteriormente la quantità di dichiarazioni di stampa che dovresti fare.

Sento che i debugger sono migliori in alcune lingue rispetto ad altre ...

La mia opinione generale è che i debugger IDE sono assolutamente incredibilmente meravigliosi per i linguaggi gestiti come Java o C #, sono abbastanza utili per C ++ e non sono molto utili per i linguaggi di scripting come Python (ma potrebbe non essere stato un buon tentativo debugger per tutti i linguaggi di scripting).

Adoro il debugger in IntelliJ IDEA quando eseguo lo sviluppo Java. Uso solo le istruzioni di stampa quando uso Python.

Come qualcuno ha detto sopra: Debugger! = IDE.

gdb e (back in the day) TurboDebugger (stand-alone) funzionano bene per le lingue che supportano [ed], grazie. (o una tecnologia ancora più vecchia: debugger Clipper collegato all'eseguibile xBase stesso) - nessuno di questi richiedeva un IDE

Inoltre, sebbene la codifica C / ++ sia più rara, le istruzioni printf a volte mascherano lo stesso bug che stai cercando di trovare! (problemi di inizializzazione in auto-variabili sullo stack, ad esempio, o allocazione / allineamento della memoria)

Infine, come altri hanno affermato, è possibile utilizzare entrambi. Alcuni problemi in tempo reale richiedono quasi una stampa, o almeno un giudizio "* video_dbg = (is_good? '+': '-');" da qualche parte nella memoria video. La mia età sta mostrando, questo era sotto DOS :-)

TMTOWTDI

Oltre a gran parte di ciò che hanno detto gli altri poster, mi piace molto passare attraverso una riga alla volta insieme al computer, poiché mi costringe a pensare a una riga alla volta. Spesso rileverò il bug senza nemmeno guardare i valori delle variabili semplicemente perché sono costretto a guardarlo mentre faccio clic sul pulsante "riga successiva". Tuttavia, non credo che la mia risposta ti aiuterà, Bill, perché probabilmente hai già questa abilità.

Per quanto riguarda le risorse di apprendimento, non ne ho usato nessuno, ho solo esplorato tutti i menu e le opzioni.

È forse una vera domanda del vero programmatore?

Chiunque abbia trascorso anche solo 5 minuti a eseguire il debug con le dichiarazioni di stampa e il debug con IDE - gli OCCORRERÀ senza nemmeno chiederlo!

Ho usato sia le stampe che gli IDE per il debug e preferirei molto il debug usando un IDE. L'unica volta in cui ciò non funziona è in situazioni critiche nel tempo (come il debug dei giochi online) in cui sporchi il codice con le istruzioni di stampa e poi guardi i file di registro dopo che è andato terribilmente storto. Quindi, se ancora non riesci a capirlo, aggiungi più stampe e ripeti.

Volevo solo menzionare una funzione utile di un debugger console vs printf e vs debugger in un IDE.

È possibile collegarsi a un'applicazione remota (ovviamente, compilata in modalità DEBUG) e controllarne lo stato scaricando l'output del debugger su un file utilizzando l' teeutilità POSIX . Rispetto a printf, è possibile scegliere dove stampare lo stato in fase di esecuzione.

Mi ha aiutato molto durante il debug delle applicazioni Adobe Flash distribuite in un ambiente aggressivo . Devi solo definire alcune azioni che stampano lo stato richiesto in ogni punto di interruzione, avviare il debugger della console confdb | tee output.log e percorrere alcuni punti di interruzione. Successivamente è possibile stampare il registro e analizzare le informazioni confrontando accuratamente lo stato in diversi punti di interruzione.

Sfortunatamente, questa funzione [registrazione su un file] è raramente disponibile nei debugger della GUI, facendo sì che gli sviluppatori confrontino lo stato degli oggetti nella loro testa.

A proposito, la mia opinione è che si dovrebbe pianificare dove e cosa eseguire il debug prima di fissare un debugger.

Bene un'altra cosa è che se ti unisci a un nuovo vecchio progetto e nessuno sa davvero come il codice sta facendo quello che sta facendo, allora non puoi eseguire il debug facendo eco a variabili / oggetti / ... b / c non hai idea di quale codice sia eseguito a tutti.

Nel mio lavoro sto affrontando esattamente quel tipo di situazione e XDebuging visivo mi aiuta a farmi un'idea di cosa sta succedendo e dove, per niente.

I migliori saluti

Raffael

Oltre alle molte cose che sono già state menzionate, uno dei vantaggi più importanti di un debugger rispetto a printf è che l'uso delle istruzioni printf presuppone che tu sappia in quale funzione risiede il bug. In molti casi non lo fai, quindi devi fare alcune ipotesi e aggiungere dichiarazioni di stampa a molte altre funzioni per localizzarlo. Il bug può essere nel codice del framework o da qualche parte molto lontano da dove pensi che sia. In un debugger è molto più semplice impostare punti di interruzione per esaminare lo stato in diverse aree del codice e in diversi punti nel tempo.

Inoltre, un debugger decente ti consentirà di eseguire il debug in stile printf collegando condizioni e azioni ai punti di interruzione, in modo da mantenere ancora i vantaggi del debug di printf, ma senza modificare il codice.

Il debug in un IDE ha un valore inestimabile in un ambiente in cui i log degli errori e l'accesso alla shell non sono disponibili, come un host condiviso. In tal caso, un IDE con un debugger remoto è l'unico strumento che ti consente di fare cose semplici come view stderro stdout.

Un problema con l'utilizzo delle istruzioni di stampa è che crea confusione nel codice. IE, hai una funzione con 10 parti e sai che si blocca da qualche parte, ma non sei sicuro di dove. Quindi aggiungi 10 dichiarazioni di stampa extra per individuare dove si trova il bug. Una volta che hai trovato e risolto il tuo bug, ora devi ripulire rimuovendo tutte quelle dichiarazioni di stampa. Forse lo farai. Forse ti dimenticherai e finirà in produzione e la console del tuo utente sarà piena di stampe di debug.

Wauw, mi piace questa domanda. Non ho mai osato posarlo ...

Sembra che le persone abbiano solo modi diversi di lavorare. Per me ciò che funziona meglio è:

• Avere un modello mentale solido del mio codice, inclusa la gestione della memoria
• Usare la strumentazione (come le dichiarazioni di stampa) per seguire ciò che sta accadendo.

Mi sono guadagnato la mia programmazione vivente da oltre 40 anni, lavorando quotidianamente in applicazioni tecniche e scientifiche non banali in C ++ e Python, e ho l'esperienza personale che un debugger non mi aiuta un po '.

Non dico che va bene. Non dico che è male. Voglio solo condividerlo.

Non è solo il debug. Un IDE ti aiuta a creare software migliore più velocemente in molti modi:

• strumenti di refactoring
• intellisense per rendere l'api più rilevabile o ricordare l'esatta ortografia / caso di oggetti familiari (non molto utile se hai usato lo stesso sistema per 15 anni, ma è raro)
• risparmia sulla digitazione completando automaticamente i nomi delle variabili e delle classi
• trova alcuni tipi di errori prima ancora di iniziare a compilare
• Passa automaticamente alle dichiarazioni / definizioni variabili / metodo / classe, anche se non si trovano nello stesso file o cartella.
• Interrompere le eccezioni non gestite e gestite

Potrei andare avanti.