Interpretazione del codice sorgente degli altri [chiuso]

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

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

Non abbiate paura di rinominare le variabili locali se sono mal denominate. (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.

Sii paziente. Capire il codice alieno non è facile, ma c'è sempre un momento di svolta quando la maggior parte dei pezzi del puzzle si innalzano all'improvviso. A quel punto è tutto un lavoro duro e faticoso, ho paura. La buona notizia è che con la pratica questo momento di eureka verrà prima.

Posso dire che penso che tu stia prendendo l'approccio sbagliato con questo. Se la gente si rivolge a te per aiuto con il suo codice, penso che tu abbia la responsabilità di girarti e dirgli di guidarti attraverso il loro codice. È possibile correggere i loro errori per loro, e possono imparare qualcosa (a memoria), se possono individuare i propri errori (con il vostro aiuto) sono suscettibili di saperne di più. Inoltre, acquisirai un'esperienza più ampia di come le diverse persone si avvicinano al codice (che a sua volta ti permetterà di leggere / comprendere più codice) - un ciclo virtuoso ...;)

Credo che questa capacità sia un mix di esperienza e di talento. Abbiamo avuto dipendenti che potrebbero risolvere più o meno qualsiasi cosa se chiedessimo loro di creare qualcosa da zero, mentre allo stesso tempo sono completamente incapaci di trovare bug ovvi in pezzi di codice che non hanno scritto. E, contemporaneamente, abbiamo avuto dipendenti di cui non ci fideremmo con qualcosa che eccedesse il design di base, ma che potevano immergersi nel codice degli altri e rintracciare i problemi in poco tempo.

Detto questo, il modo di avvicinarsi a questo è cambiare il codice. Riformatelo su ciò che siete abituati, cambiate i nomi delle variabili in qualcosa che abbia senso per voi, aggiungete commenti se il codice non è chiaro. Se ti ha chiesto aiuto, dovresti solo andare avanti e cambiare le cose fino ad individuare il problema. Quindi lascia a tuo amico se correggere il codice originale o usare il tuo.

Innanzitutto, se ci sono errori di sintassi, devi semplicemente leggere attentamente gli errori del compilatore. Spesso una linea è evidenziata come un errore, ma in realtà era la precedente linea che ha l'errore.

Tieni presente che, per uno studente introduttivo, potrebbero esserci alcuni artefatti di modifica che impediranno la compilazione del programma che non può essere visto. Per esempio, una volta ho visto uno studente (non uno dei miei) che ha usato la barra spaziatrice invece di tornare: il suo codice sembrava normale su un editor che avvolgeva dopo 80 colonne (lo studente era molto paziente) e il codice funzionava fino a quando non ha aggiunto un " // " - commento di stile, che ha commentato tutto il resto del programma. Allo stesso modo, se si copiano campioni 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 dubbio, digitare nuovamente una riga senza copiare e incollare. [È un po 'stupefacente, ma ultimamente ho visto accadere molto di più.]

Per errori di compilatore sgradevoli, potresti dover far crescere il programma, creando un nuovo file e digitando tutto il codice mentre procedi. Assicurati di compilare dopo ogni passaggio principale prima di passare a quello successivo.

OK, quindi cosa succede se non ci sono errori di sintassi? Quindi è il momento di scorrere il codice! È possibile utilizzare un debugger per questo, ma anche effettuare chiamate a printf in tutto il codice è molto efficace. Ad esempio, se esiste un ciclo for , aggiungere un'istruzione di stampa per il contatore di loop. Nel caso di cicli nidificati di for , potresti scoprire che la variabile errata viene incrementata.

Il vantaggio di usare printf s è la sua capacità di "comprimere" nel tempo / spazio ciò che stai attualmente guardando. Quando si esegue un debugger, si vede anche un sacco di stato irrilevante e può essere più noioso. Inoltre, senza vedere una cronologia di ciò che è stato stampato sulla console, potresti perdere alcuni pattern. 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 realizzare il modo in cui concettualizzavano il programma aveva un difetto, che può portarti a una soluzione.

Come commentato altrove, tutto 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 ad aiutarli con i loro errori.

Detesto dire questo, ma qui non c'è un proiettile d'argento.

Francamente, se fossi abbastanza chiaroveggente da essere in grado di capire che cosa intendevano quando hanno scritto quello che hanno fatto anche nel 10% dei casi, senza dubbio avrei fatto milioni di dollari 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 consiste nel trovare 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 globali se li stai utilizzando. Chiedete anche ai vostri amici se stanno usando un algoritmo specifico conosciuto - la lettura dell'algoritmo (se ne esiste uno) prima di guardare il codice è sempre vantaggioso.

In una parola: esperienza, più guadagni esperienza, più impari delle 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 si guarda il codice spesso è solo il risultato di un processo di pensiero importante che spesso è molto difficile estrapolare dal codice. Alcuni commenti, un file di testo con pensieri di progettazione può fare la differenza tra la comprensione del codice e l'incomprensione del tutto.

Spesso mi è stato chiesto lo stesso in laboratorio a scuola. Di solito la domanda iniziava con "Come posso risolvere questo errore del compilatore?" quindi sono diventato abbastanza bravo a individuare il dangling else , mancando il punto e virgola e simili. (Anche i macro sono divertenti da debugare - #define CUBE(x) x * x * x è un errore che tutti siamo destinati a fare.) Un vantaggio che avevo era che avevo passato le stesse lezioni con gli stessi insegnanti, quindi avevo già familiarità con i requisiti. / p>

Il processo che ho trovato utile è 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 nello stesso computer con loro. Nel laboratorio sarei venuto 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 c'è più di uno degli stessi errori, chiedo loro cosa fosse simile ai due errori.

L'idea è di aiutare a guidare l'altro studente. Riscrivere il loro codice per loro non li aiuterà a 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 al suo interno e correggi gli errori. Gli errori logici sono molto più difficili. Non sono sicuro del perché tu dica che non puoi chiedere loro di spiegare il loro codice. Ho trovato molti errori logici spiegando il codice a qualcun altro.