Code lesen lernen?

2 Antworten

Vom Beitragsersteller als hilfreich ausgezeichnet

1) Es gibt einige Webseiten, auf denen Algorithmen geteilt werden. Du könntest zunächst versuchen, selbst den genauen Ablauf zu verstehen und dir im Anschluss Erklärungen dazu heraussuchen.

Zuallererst würde mir da Rossetta Code einfallen und als Zweites Wikipedia. Zugegeben, kannst du da auf ziemlich komplizierte Exemplare stoßen, bei denen es dann nicht so viel Sinn macht, zu versuchen, einzutauchen. Daher hier ein paar Vorschläge, mit welchen du dich auseinandersetzen könntest:

  • Caesar-Chiffre, Vigenère-Chiffre
  • Suchalgorithmen (inbegriffen: Minimax, Negamax)
  • Sortieralgorithmen
  • Tree traversal (inorder, preorder, postorder)
  • Pathfinding, Dijkstra

2) Auf GitHub findest du eine extrem große Anzahl an Projekten von Entwicklern aller Welt. Von Interesse wären hierbei eher kleine Projekte - dementsprechend könntest du nach Implementationen von Minispielen (Pong, Tetris, Pacman, ...) Ausschau halten.

Wenn du dir mehr zutraust, könntest du bei bestehenden (am besten nach wie vor eher kleinen Projekten) Bug Hunting betreiben oder in einem Fork schauen, inwiefern du Code optimieren kannst (sei es in der Leistungsfähigkeit, Stabilität oder Lesbarkeit).

3) Vielleicht kennst du jemanden, der dir eigene Codes zuschicken kann, die du dann versuchst, zu lesen. Oder du versuchst in eine Projektarbeit mit jemanden anders zu kommen und führst dort dann Code Reviews durch.

4) Auf CodinGame, CodeCombat und Untrusted gibt es jeweils Tutorials, bei denen du die Aufgabe bekommst, bestimmte Programme zu erweitern. Dazu solltest du also erst einmal den Programmcode verstehen. Hierzu sei allerdings gesagt, dass es sich konzentriert um Lernplattformen für Anfänger handelt. Daher wirst du, zumindest auf den unteren Stufen, sicherlich nicht so sehr gefordert werden.

Zuletzt noch Herangehensweisen, um sich das Lesen von Code zu vereinfachen:

1) Eine der wichtigsten Voraussetzungen ist gut formatierter Code, der sich einheitlich an irgendeine Konvention hält. Wenn du auf Code stößt, der solche Merkmale nicht aufweist, wäre ein Code Refactoring praktisch.

2) Bei kleinen Programmen / Programmabschnitten / Algorithmen kann es hilfreich sein, sich Skizzen anzufertigen oder den Ablauf mit einem PAP oder Stichpunkten nachzubauen. Setze, sofern es dir möglich ist, konkrete Werte für Variablen ein (am besten kleine/kurze, bei Zahlen wären z.B. ganze Zahlen günstig) und gehe Schritt für Schritt mit diesen Werten durch die Anweisungen. Notiere dir Zwischenergebnisse.

3) Sicherlich wirst du mit einer IDE wie Eclipse, Visual Studio, IntelliJ, o.ä. arbeiten. Lerne sie auf jeden Fall besser kennen. Oft gibt es eine Vielzahl an Tools, die dir bei der Codeanalyse unterstützen können. Eines davon wäre beispielsweise der Debugger. Mache dich unbedingt mit ihm vertraut, denn nicht jedes Programm lässt sich so, wie in Punkt 2 vorgeschlagen, analysieren.

4) Arbeite eng mit Dokumentationen zusammen. Nimm dir die Zeit, zu recherchieren.

Ich hab das Problem, dass ich zwar über meinen eigenen Code schauen kann, da ich ja weiß was er macht und wo er was macht, aber schnell Probleme bekomme, wenn ich den Code von anderen lese.

Das ist normal und geht uns wohl allen so.

Wo immer ich in die Situation kam, mich im Code anderer zurechtfinden zu müssen, gelang mir das in nennenswertem Umfang erst, nachdem ich (mit einem dafür durch mich extra hierfür entwickelten Reengineering-Werzeug) den fremden Code in HTML-Darstellung gebracht hatte mit jeder Menge von Links, ihn schnell datei-übergreifend durchwandern zu können. [ Code zu lesen sollte zunächst mal keinerlei Kenntnis darüber erfordern, wie er sich auf Dateien verteilt. ]

Ich und einige meiner Kollegen haben mit diesem Ansatz dann aber wirklich gute Erfahrungen gemacht (betrachter Code waren, je nach Projekt, große Mengen Java, C++ und COBOL).

PS: Unser zunächst nur Java verstehendes Werkzeug auf COBOL anzupassen gelang mir problemlos, obgleich ich selbst nie Code in COBOL geschrieben hatte (was bis heute so ist).


Eisenschlumpf  23.12.2021, 09:45

Zusätzlich ist es hilfreich, konsequent zu schreiben, in Abschnitte zu gliedern und viel zu kommentieren. Auch wenn es für die Autoren selbst "logisch ist", was die einzelnen Abschnitte bewirken, weil sie in der Materie sind, kann es nie schaden, trotzdem zu kommentieren, was da geschieht.

Ich habe es schon mehrfach erlebt, dass Arbeit von anderen übernommen werden musste (plötzliches Beenden des Beschäftigungsverhältnisses bzw. einmal Tod des Arbeitnehmers) und der, der sich neu mit der Sache beschäftigt hat, musste sich mühsam hineinarbeiten, obwohl er sich in der Sprache recht gut auskannte. Das lag daran, dass die Ursprungsautoren sich nicht drum gekümmert haben, wie deren Werke aussehen und weder in den Kommandostrukturen noch in den Variablen und Bezügen einheitlich gearbeitet haben. Funktioniert hat alles, aber es war unübersichtlich. Erweiterungen und Änderungen sind in solchen Systemen kompliziert.

Wenn in verschiedenen Bereichen (z. B. Anmeldung, Buchung, E-Mail-Angaben) eine Variable "Name" steht, die im gesamten Code mehrfach vorkommt, aber dank gewissen Mechanismen von den codelesenden Programmen nie über die einzelnen Bereiche hinaus verwechselt werden kann, kann das funktionieren. Trotzdem wäre es besser, wenn man auch codisch eindeutige Variablen nimmt, die auch bereichsübergreifend eindeutig sind, beispielsweise "Anmeldename", "Buchungsname", "Mailname".

Ich schreibe nicht viel an Code und weiß, dass ich ein schlechter Schreiber bin. Darum kommentiere ich viel, weil ich will, dass jeder meinen Code versteht und problemlos selber dran arbeiten kann. Königswissen bringt mich nicht weiter. Meine Kolleginnen brauchen meine Kommentare nicht, weil sie wenig wissen, sondern weil ich mich nicht gut genug auskenne und daher manches umständlicher mache, als es nötig ist. Dank den Kommentaren erhalte ich regelmäßig Verbesserungen in meinem Code und Tipps, wie man das einfacher machen kann. Wir lernen so voneinander: Sie von mir, was ich nicht kann und was ich falsch mache und ich erhalte von ihnen praktischen Unterricht.

1