Interpretazione del codice sorgente di altri [chiuso]

Nota: sono a conoscenza di questa domanda. Questa domanda è un po 'più specifica e approfondita, tuttavia, concentrandosi sulla lettura del codice effettivo piuttosto che sul debug o sulla domanda all'autore.

Come studente in una lezione di informatica di livello introduttivo, i miei amici ogni tanto mi chiedono di aiutarli con i loro compiti. La programmazione è qualcosa di cui sono molto orgoglioso, quindi sono sempre felice di accontentare. Tuttavia, di solito ho difficoltà a interpretare il loro codice sorgente.

A volte questo è dovuto a uno stile strano o incoerente, a volte è dovuto a strani requisiti di progettazione specificati nell'incarico, a volte è dovuto solo alla mia stupidità. In ogni caso, finisco per sembrare un idiota che fissa lo schermo per diversi minuti dicendo "Uh ..."

Di solito cerco prima gli errori comuni: punto e virgola mancanti o parentesi, usando virgole invece di operatori di estrazione, ecc.

Il problema arriva quando fallisce. Spesso non riesco a entrare in contatto con un debugger perché è un errore di sintassi e spesso non posso chiedere all'autore perché non comprende le decisioni di progettazione.

Come leggi in genere il codice sorgente di altri? Leggi il codice dall'alto verso il basso o segui ciascuna funzione come viene chiamata? Come fai a sapere quando dire "È tempo di refactoring?"

Primo consiglio: usa un IDE (o un ottimo editor :)) per individuare errori di sintassi, parentesi fuori posto e altri errori banali.

Secondo passaggio: formattare automaticamente tutto il codice in un formato con cui ti senti a tuo agio. Penseresti che questo non importa molto, ma sorprendentemente, lo fa.

Non abbiate paura di rinominare le variabili locali se sono mal nominate. (Se hai accesso al sistema completo, puoi rinominare qualsiasi cosa e dovresti.)

Aggiungi commenti a te stesso quando scopri cosa sta facendo una determinata funzione / metodo.

Essere pazientare. Comprendere il codice alieno non è facile, ma c'è sempre un momento decisivo in cui la maggior parte dei pezzi del puzzle si posizionano all'improvviso. Fino a quel momento ho tutto il duro lavoro e la fatica, temo. La buona notizia è che con la pratica questo momento eureka arriverà prima.

Posso dire che penso che tu stia adottando un approccio sbagliato con questo. Se le persone si rivolgono a te per chiedere aiuto con il loro codice, penso che tu abbia la responsabilità di voltarti e dire loro di guidarti attraverso il loro codice. Puoi correggere i loro errori per loro, e possono imparare qualcosa (per voto), se riescono a individuare i propri errori (con il tuo aiuto) è probabile che imparino di più. Inoltre, acquisirai una più ampia esperienza su come le diverse persone si avvicinano alla programmazione (che a sua volta ti permetterà di leggere / comprendere più codice) - un ciclo virtuoso ...;)

Credo che questa capacità sia un mix di esperienza e che abbia solo un talento per questo. Abbiamo avuto impiegati che potevano risolvere più o meno qualsiasi cosa se avessimo chiesto loro di fare qualcosa da zero, mentre allo stesso tempo non eravamo completamente in grado di trovare ovvi bug in pezzi di codice che non scrivevano. E, contemporaneamente, abbiamo avuto dipendenti di cui non ci saremmo fidati di qualcosa che eccedesse il design di base, ma che potevano immergersi nel codice degli altri e rintracciare i problemi in pochissimo tempo.

Detto questo, il modo di accedervi è cambiare il codice. Riformattalo in base a ciò a cui sei abituato, cambia i nomi delle variabili in qualcosa che ha senso per te, aggiungi commenti se il codice non è chiaro. Se ti ha chiesto aiuto, dovresti semplicemente andare avanti e cambiare le cose fino a individuare il problema. Quindi lascia al tuo amico se correggere il codice originale o utilizzare il tuo.

Innanzitutto, se ci sono errori di sintassi, devi semplicemente leggere attentamente gli errori del compilatore. Spesso una riga viene evidenziata come errore, ma in realtà era la riga precedente a presentare l'errore.

Tenere presente che, per uno studente introduttivo, potrebbero esserci alcuni artefatti di modifica che impediranno la compilazione del programma che non è possibile visualizzare. Ad esempio, una volta ho visto uno studente (non uno dei miei) che ha usato la barra spaziatrice invece di return: il suo codice sembrava normale su un editor che si svolgeva dopo 80 colonne (lo studente era molto paziente) e il codice ha funzionato fino a quando non ha aggiunto un //commento in stile " ", che ha commentato tutto il resto del programma. Allo stesso modo, se copi esempi di codice da un sito Web, spesso vengono copiati anche caratteri non stampabili (a seconda di come il sito Web ha formattato il codice). In caso di dubbi, digitare nuovamente una riga senza copiare e incollare. [È un po 'sorprendente, ma ho visto succedere molto di più ultimamente.]

Per cattivi errori del compilatore, potrebbe essere necessario aumentare il programma, creando un nuovo file e digitando tutto il codice man mano che procedi. Assicurati di compilare dopo ogni passaggio principale prima di passare al successivo.

OK, e se non ci fossero errori di sintassi? Quindi è il momento di scorrere il codice! È possibile utilizzare un debugger per questo, ma anche effettuare chiamate in printftutto il codice è molto efficace. Ad esempio, se esiste un forloop, aggiungi un'istruzione print per il contatore loop. Nel caso di forloop nidificati , è possibile che si stia incrementando la variabile errata.

Il vantaggio di usare printfs è la sua capacità di "comprimere" nel tempo / spazio ciò che stai guardando. Quando passi attraverso un debugger, vedi anche molto stato irrilevante e può essere più noioso. Inoltre, senza vedere una cronologia di ciò che è stato stampato sulla console, potresti perdere alcuni schemi. Il punto qui è che il debugger e printfs sono tecniche complementari e nessuno dei due è sempre migliore dell'altro.

Infine, chiedi semplicemente al tuo amico cosa sta succedendo! Invece di guardarlo e dire "uh" chiedi loro cosa stanno facendo: "ora cosa fa n?" Avviando la finestra di dialogo, potrebbero finire per rispondere alla loro stessa domanda, oppure, potresti capire il modo in cui hanno concettualizzato che il programma aveva un difetto, il che può condurti a una soluzione.

Come commentato altrove, tutto ciò migliora con l'esperienza. Anche se ho programmato per 20 anni, è stato solo negli ultimi 5 anni che ho lavorato con gli studenti che sono migliorato nell'aiutarli con i loro errori.

Odio dirlo, ma non c'è proiettile d'argento qui.

Francamente se fossi abbastanza chiaroveggente da essere in grado di capire cosa intendevano gli altri quando scrivevano quello che facevano anche nel 10% dei casi, senza dubbio ne avrei guadagnati milioni ormai.

Su una nota più pratica, l'utilizzo di un IDE intelligente è il passaggio 1.

Il passaggio 2 sarebbe eseguire doxygen o qualcosa di simile per capire la gerarchia del codice sorgente.

Il passaggio 3 è scoprire funzioni o oggetti di ancoraggio, elementi che elaborano la riga di comando o il file e quindi eseguono la logica.

Parallelamente al passaggio 3, tieni traccia dei globi se li stai usando. Chiedi anche ai tuoi compagni se stanno usando un algoritmo specifico noto: leggere l'algoritmo (se esiste) prima di guardare il codice è sempre utile.

In una parola: esperienza, più acquisisci esperienza, più apprendi le migliori pratiche e puoi giudicare / comprendere il codice di altre persone. Non viene automaticamente, ma spesso viene solo dallo stesso errore!

Detto questo, è essenziale che i programmatori imparino a commentare correttamente il loro codice perché quando guardi il codice spesso è solo il risultato di un importante processo di pensiero che spesso è molto difficile estrapolare dal codice. Alcuni commenti, un file di testo con idee progettuali può fare la differenza tra comprendere il codice e fraintenderlo completamente.

Mi è stato spesso chiesto lo stesso in laboratorio a scuola. Di solito la domanda è iniziata con "Come posso correggere questo errore del compilatore?" così sono diventato abbastanza bravo a individuare penzoloni else, punti e virgola mancanti e simili. (Anche le macro sono divertenti per il debug - #define CUBE(x) x * x * xè un errore che tutti siamo destinati a fare.) Un vantaggio che ho avuto è stato il fatto di aver frequentato le stesse classi con gli stessi insegnanti, quindi avevo già familiarità con i requisiti.

Il processo che ho trovato funzionare meglio è mantenere una finestra di dialogo in esecuzione. Non vuoi scrivere il programma per loro, poiché sono quelli che devono imparare. Ciò significa che devi essere sullo stesso computer con loro. In laboratorio verrei al loro computer. Vorrei provare a far loro individuare l'errore, iniziando con il messaggio del compilatore. (Stavamo usando C.) Inizia con il numero di riga e indica dove corrispondono il messaggio e l'errore. Se esiste più di uno stesso errore, chiederei loro cosa era simile ai due errori.

L'idea è di aiutare a guidare l'altro studente. Riscrivere il loro codice per loro non li aiuterà ad imparare.

Gli errori di sintassi sono molto più facili da trovare rispetto agli errori logici. Se la maggior parte dei loro problemi sono sintassi, trova un IDE, copia e incolla il loro codice e correggi gli errori. Gli errori logici sono molto più difficili. Non sono sicuro del motivo per cui dici che non puoi chiedere loro di spiegare il loro codice. Ho riscontrato molti errori logici spiegando il codice a qualcun altro.