Interpretation des Quellcodes anderer [geschlossen]

Hinweis: Diese Frage ist mir bekannt . Diese Frage ist jedoch etwas spezifischer und ausführlicher und konzentriert sich darauf, den eigentlichen Code zu lesen, anstatt ihn zu debuggen oder den Autor zu fragen.

Als Student in einem Informatik-Einführungskurs bitten mich meine Freunde gelegentlich, ihnen bei ihren Aufgaben zu helfen. Das Programmieren ist etwas, auf das ich sehr stolz bin, deshalb bin ich immer gerne bereit, es zu tun. Normalerweise habe ich jedoch Schwierigkeiten, ihren Quellcode zu interpretieren.

Manchmal liegt dies an einem seltsamen oder inkonsistenten Stil, manchmal an seltsamen Designanforderungen, die in der Aufgabe angegeben sind, und manchmal nur an meiner Dummheit. Auf jeden Fall sehe ich aus wie ein Idiot, der einige Minuten lang auf den Bildschirm starrt und sagt "Äh ..."

Normalerweise überprüfe ich zuerst die häufigsten Fehler - fehlende Semikolons oder Klammern, Kommas anstelle von Extraktoroperatoren usw.

Das Problem tritt auf, wenn dies fehlschlägt. Ich kann mit einem Debugger oft nicht durchkommen, weil es sich um einen Syntaxfehler handelt, und ich kann den Autor oft nicht fragen, weil er / sie selbst die Entwurfsentscheidungen nicht versteht.

Wie liest man normalerweise den Quellcode anderer? Lesen Sie den Code von oben nach unten durch oder folgen Sie jeder Funktion, wie sie aufgerufen wird? Woher wissen Sie, wann Sie sagen müssen: "Es ist Zeit für eine Umgestaltung?"

Erster Tipp: Verwenden Sie eine IDE (oder einen sehr guten Editor :)), um Syntaxfehler, falsch platzierte Klammern und andere triviale Fehler zu erkennen.

Zweiter Schritt: Formatieren Sie den gesamten Code automatisch in einem Format, mit dem Sie sich wohl fühlen. Sie würden denken, dass dies nicht viel ausmacht, aber erstaunlicherweise.

Haben Sie keine Angst, lokale Variablen umzubenennen, wenn sie schlecht benannt sind. (Wenn Sie Zugriff auf das gesamte System haben, können Sie alles umbenennen und sollten dies tun.)

Fügen Sie sich Kommentare hinzu, wenn Sie feststellen, was eine bestimmte Funktion / Methode tut.

Sei geduldig. Das Verstehen von Alien-Code ist nicht einfach, aber es gibt immer einen Durchbruch, wenn die meisten Teile des Puzzles plötzlich zusammenfallen. Bis dahin ist alles harte Arbeit und Plackerei, fürchte ich. Die gute Nachricht ist, dass dieser Eureka-Moment mit der Übung früher kommen wird.

Darf ich sagen, dass ich denke, dass Sie damit den falschen Ansatz verfolgen. Wenn sich Leute an Sie wenden, um Hilfe bei ihrem Code zu erhalten, haben Sie wahrscheinlich die Verantwortung, sich umzudrehen und ihnen zu sagen, dass sie Sie durch ihren Code führen sollen. Sie können ihre Fehler für sie beheben, und sie können etwas (auswendig) lernen. Wenn sie ihre eigenen Fehler (mit Ihrer Hilfe) erkennen können, werden sie wahrscheinlich mehr lernen. Darüber hinaus werden Sie umfassendere Erfahrungen mit der Herangehensweise verschiedener Personen an das Codieren sammeln (wodurch Sie wiederum mehr Code lesen / verstehen können) - ein tugendhafter Zyklus ...;)

Ich glaube, diese Fähigkeit ist eine Mischung aus Erfahrung und Talent. Wir hatten Mitarbeiter, die mehr oder weniger alles lösen konnten, wenn wir sie baten, etwas von Grund auf neu zu machen, während sie gleichzeitig keine offensichtlichen Fehler in Codeteilen finden konnten, die sie nicht geschrieben hatten. Gleichzeitig hatten wir Mitarbeiter, denen wir nichts anvertrauen würden, das über das grundlegende Design hinausgeht, die aber in kürzester Zeit in anderen Code eintauchen und Probleme aufspüren könnten.

Der Weg, dies zu erreichen, besteht darin, den Code zu ändern. Formatieren Sie es neu, wie Sie es gewohnt sind, ändern Sie Variablennamen in etwas, das für Sie sinnvoll ist, und fügen Sie Kommentare hinzu, wenn der Code nicht klar ist. Wenn er Sie um Hilfe gebeten hat, sollten Sie einfach die Dinge ändern, bis Sie das Problem erkennen. Überlassen Sie es dann Ihrem Freund, den Originalcode zu korrigieren oder Ihren zu verwenden.

Wenn Syntaxfehler auftreten, müssen Sie zunächst die Compilerfehler sorgfältig lesen. Oft wird eine Zeile als Fehler hervorgehoben, aber es war tatsächlich die vorherige Zeile, die den Fehler aufweist.

Beachten Sie, dass es für einen Einführungsstudenten möglicherweise einige Bearbeitungsartefakte gibt, die verhindern, dass das Programm kompiliert wird und nicht sichtbar ist. Zum Beispiel habe ich einmal einen Schüler gesehen (keinen von mir), der die Leertaste anstelle der Rückgabe verwendet hat: Sein Code sah in einem Editor, der nach 80 Spalten umbrochen wurde, normal aus (der Schüler war sehr geduldig), und der Code funktionierte sogar, bis er hinzufügte Ein //Kommentar im " " -Stil, der den gesamten Rest des Programms auskommentierte. Wenn Sie Codebeispiele von einer Website kopieren, werden häufig auch nicht druckbare Zeichen kopiert (abhängig davon, wie die Website den Code formatiert hat). Geben Sie im Zweifelsfall eine Zeile ohne Kopieren und Einfügen erneut ein. [Es ist erstaunlich, aber ich habe in letzter Zeit viel mehr gesehen.]

Bei bösen Compilerfehlern müssen Sie das Programm möglicherweise erweitern, indem Sie eine neue Datei erstellen und den gesamten Code eingeben. Stellen Sie sicher, dass Sie nach jedem wichtigen Schritt kompilieren, bevor Sie mit dem nächsten fortfahren.

OK, was ist, wenn keine Syntaxfehler vorliegen? Dann ist es Zeit, den Code durchzugehen! Sie können hierfür einen Debugger verwenden, aber auch Anrufe im printfgesamten Code sind sehr effektiv. Wenn beispielsweise eine forSchleife vorhanden ist, fügen Sie eine print-Anweisung für den Schleifenzähler hinzu. Bei verschachtelten forSchleifen stellen Sie möglicherweise fest, dass die falsche Variable inkrementiert wird.

Der Vorteil der Verwendung von printfs ist die Fähigkeit, das, was Sie gerade betrachten, über Zeit / Raum zu "komprimieren". Wenn Sie mit einem Debugger durchgehen, sehen Sie auch viele irrelevante Zustände und es kann langwieriger sein. Ohne einen Verlauf dessen zu sehen, was auf der Konsole gedruckt wurde, können einige Muster fehlen. Der Punkt hier ist, dass der Debugger und printfs komplementäre Techniken sind und keine immer besser ist als die andere.

Fragen Sie zum Schluss einfach Ihren Freund, was los ist! Anstatt es anzusehen und "äh" zu sagen, fragen Sie sie, was sie tun: "Was macht es njetzt?" Wenn Sie den Dialog starten, beantworten sie möglicherweise ihre eigene Frage, oder Sie stellen fest, dass die Art und Weise, wie sie das Programm konzipiert haben, einen Fehler aufweist, der Sie zu einer Lösung führen kann.

Wie an anderer Stelle kommentiert, wird dies alles mit der Erfahrung besser. Obwohl ich seit 20 Jahren programmiere, habe ich erst in den letzten 5 Jahren mit Studenten zusammengearbeitet, um ihnen bei ihren Fehlern zu helfen.

Ich hasse es, das zu sagen, aber hier gibt es keine Silberkugel.

Ehrlich gesagt, wenn ich hellsichtig genug wäre, um zu verstehen, was andere meinten, als sie schrieben, was sie selbst in 10% der Fälle taten, würde ich ohne Zweifel inzwischen Millionen verdienen.

Praktischer ausgedrückt ist die Verwendung einer intelligenten IDE Schritt 1.

Schritt 2 wäre, doxygen oder ähnliches auszuführen, um die Quellcode-Hierarchie herauszufinden.

Schritt 3 besteht darin, Ankerfunktionen oder -objekte herauszufinden, die Ihre Befehlszeile oder Datei verarbeiten und dann Logik ausführen.

Verfolgen Sie parallel zu Schritt 3 die Globals, wenn Sie sie verwenden. Fragen Sie Ihre Kollegen auch, ob sie einen bekannten spezifischen Algorithmus verwenden. Das Lesen des Algorithmus (falls vorhanden) vor dem Betrachten des Codes ist immer von Vorteil.

Mit einem Wort: Erfahrung: Je mehr Erfahrung Sie sammeln, desto mehr lernen Sie über Best Practices und können den Code anderer Personen beurteilen / verstehen. Es kommt nicht automatisch, sondern oft nur, weil Sie den gleichen Fehler selbst gemacht haben!

Das heißt, es ist wichtig, dass Programmierer lernen, ihren Code richtig zu kommentieren, denn wenn Sie sich Code ansehen, ist dies oft nur das Ergebnis eines großen Denkprozesses, der oft sehr schwer aus dem Code zu extrapolieren ist. Ein paar Kommentare, eine Textdatei mit Designgedanken, können den Unterschied zwischen dem Verstehen des Codes und dem völligen Missverständnis des Codes ausmachen.

Im Labor in der Schule wurde ich oft gleich gefragt. Normalerweise begann die Frage mit "Wie behebe ich diesen Compilerfehler?" so wurde ich ziemlich gut darin, baumelnde else, fehlende Semikolons und dergleichen zu erkennen. (Das Debuggen von Makros macht auch Spaß - #define CUBE(x) x * x * xein Fehler, den wir alle machen müssen.) Ein Vorteil, den ich hatte, war, dass ich dieselben Klassen mit denselben Lehrern durchlaufen hatte, sodass ich bereits mit den Anforderungen vertraut war.

Der Prozess, den ich am besten fand, besteht darin, einen laufenden Dialog zu führen. Sie möchten das Programm nicht für sie schreiben, da sie lernen müssen. Dies bedeutet, dass Sie mit ihnen am selben Computer sitzen müssen. Im Labor würde ich zu ihrem Computer kommen. Ich würde versuchen, sie dazu zu bringen, den Fehler zu erkennen, indem ich mit der Compiler-Nachricht beginne. (Wir haben C verwendet.) Beginnen Sie mit der Zeilennummer und weisen Sie darauf hin, wo die Meldung und der Fehler übereinstimmen. Wenn es mehr als einen Fehler gibt, würde ich sie fragen, was an den beiden Fehlern ähnlich ist.

Die ganze Idee ist, den anderen Schüler zu führen. Das Umschreiben ihres Codes für sie hilft ihnen nicht beim Lernen.

Syntaxfehler sind viel einfacher zu finden als Logikfehler. Wenn die meisten Probleme in der Syntax liegen, suchen Sie eine IDE, kopieren Sie den Code, fügen Sie ihn ein und beheben Sie die Fehler. Logikfehler sind viel schwieriger. Ich bin mir nicht sicher, warum Sie sagen, dass Sie sie nicht bitten können, ihren Code zu erklären. Ich habe so manchen logischen Fehler gefunden, indem ich jemand anderem den Code erklärt habe.