Das ist eine Frage, in der man ein paar "Best Practices" nennen kann, bei der man aber NICHT (direkt) den Finger draufhalten kann nach dem Motto: "SO muss das"... Aber generell kommt sowas mit der Zeit und genügend Übung. Irgendwann macht man zwangsläufig Fehler (was gerade in der Anfangszeit völlig normal beim Programmieren ist) und dann merkt man auch selbst, was für Nachteile man hat, weil man dieses oder jenes nicht so stark berücksichtigt hat beim Korrigieren. *Wenn* man den Fehler gemacht hat, kann man natürlich auch draufzeigen^^.
- Einrückungen verwenden (erwähne ich der Vollständigkeit halber, weil das in *allen* höheren Programmiersprachen gilt; in Python ist es ja fast nicht möglich, Einrückungen zu ignorieren)
- Wie Sirius3 schon sagt:
Don't repeat yourself. Wenn du mehrmals fast exakt denselben Quelltext schreibst und nur minimal was änderst, ist das fast immer ein Indikator dafür, dass sowas womöglich besser in einer Funktion oder einer Schleife aufgehoben ist. Reduziert die Zahl der Quelltextzeilen und sorgt dafür, dass du ggf. bei einer Änderung im Quelltext diese nicht an mehreren Stellen vornehmen musst (was fehleranfällig ist, erst recht wenn man einen Quelltext erst nach längerer Zeit wieder öffnet, weil man zwischendurch das Geschriebene großteils wieder vergessen hat)
- Kommentare und, was speziell Python angeht, Docstrings sinnvoll benutzen. Bei Kommentaren gilt: Nicht schreiben, "was" der Quelltext macht (das sieht man ja am Quelltext schon selbst) sondern *wie* oder *warum* man etwas im Quelltext macht.
- Es hilft auch sehr schön, sich "fremden" Quelltext von anderen Leuten anzusehen. Einerseits um sich Methoden abzuschauen ("ach, SO hat er das Problem gelöst"), andererseits wird einem dabei sehr schnell sehr deutlich vor Augen geführt, wie "lesbar" der Quelltext für einen selber ist - und sich, je nach Qualität des Quelltextes, selber daran zu halten oder als mahnendes Beispiel, wie der eigene Quelltext auf andere wirkt, davon abzusehen.
- Eindeutige Variablennamen verwenden. "x" und "y" können als Namen bei Positionsbeschreibungen gerade noch so in Ordnung gehen, und wenn eine Variable nur übergangsweise für die nächsten 3-4 Zeilen (hypothetische Zahlen) verwendet und danach nichtmehr gebraucht wird, ist der Name auch nicht so wichtig. Aber für alles, womit man längerfristig arbeitet, sollte man sinnvolle Namen wählen. Wenn ein mehrere hundert Zeilen großer Quelltext völlig abhängig von einer Variable namens "tmp" ist, dann ist was gehörig schiefgelaufen^^.
- Ist zwar eine Geschmacksfrage, aber dennoch: Selbst bei kleineren Projekten würde ich schon auf eine einigermaßen brauchbare IDE zurückgreifen, die z.B. Syntaxhervorhebung bietet und auch alle geschriebenen Funktionen, Klassen und Methoden in einer Liste darstellt. Zur Not Geany (auch wenn das Ding merkwürdige Voreinstellungen bei der Einrückung hat - unbedingt in den Optionen dafür sorgen, dass Geany Tabs in Leerzeichen umwandelt, falls man Geany wirklich benutzen will!), aber welchen Editor man schlussendlich nutzen mag, bestimmt jeder für sich selbst.
- Ein Fehler, den auch hin und wieder Anfänger machen: Bloß nicht damit anfangen, den Quelltext irgendwie "optisch zu dekorieren". Was nützt es, wenn jede einzelne Quelltextzeile an exakt derselben Spalte aufhört, wenn dadurch die Lesbarkeit stark drunter leidet? Quelltext wird öfters gelesen als er geschrieben wird, dementsprechend sollte auch der Fokus gesetzt werden.
- Bei größeren Quelltexten ist es auch oft eine gute Idee, diese in mehrere Dateien aufzuteilen. Funktionen und Klassen sollte man idealerweise eh nie zu lang werden lassen (weil dann die Gefahr besteht, dass es sich um
Gottklassen handeln), aber auch für die Wiederverwendbarkeit kann es sinnvoll sein, thematisch "verwandte" Funktionen in eine andere Quelltext-Datei auszulagern. Aber auch das ist was, was man irgendwann selbst herausfindet - wenn der eigene Quelltext 5000 Zeilen umfasst und man mehr mit Scrollen als mit Quelltextschreiben beschäftigt ist, weiß man, dass man da was tun muss, ums mal nett zu formulieren^^.