Hallo.
Weil ich mich gerade um meine Arbeit drücken möchte
main.py:
- Du brauchst nicht mit "#imports" kennzeichnen, dass die Importe anfangen, dass sieht man auch so
- Schreibe keinen Code auf Modul-Ebene, packe alles in Funktionen. Sonst kannst du das Modul nicht vernünftig wiederverwenden. Am besten alles in eine main-Funktion packe und so aufrufen:
Dann wird der Code nur ausgeführt, wenn du das Programm aufrufst aber nicht, wenn du es importierst.
- Alles was kein Integer ist sollte nicht an den Namen `i` gebunden werden.
- Die while-Schleife würde man eher als `while(True)` schreiben und bei `exit` mit `break` verlassen.
- Wenn du viele `elif`s hast in denen du immer den selben Namen auf Gleichheit testest, dann solltest du ein Dictionary verwenden und die Fälle in Funktionen aufteilen.
- Du hast überall magische Zahlen stehen, packe diese in Konstanten, sonst weist du in einer Woche schon nicht mehr, was sie bedeuten.
- Wenn du den selben Ausdruck mehrmals schreibst, dann denke über Variablen nach
- Strings werden nicht mit `+` zusammengesetzt, benutze dazu die gelieferten String Formatting Methoden
- Die `print`-Funktion kann mehrere Argumente entgegennehmen, dann spart man sich evtl. das Zusammensetzen von Strings.
- `x == False` solltest du besser als `not x` schreiben.
- Warum gibst du am Anfang immer die Hilfe aus?
help.py:
- Konstanten solltest du durchgehend in Großbuchstaben schreiben (PEP

- Es gibt `__author__` und `__version__`
- Wenn die Datei zu Ende ist, dann weiß auch jeder das nichts mehr kommt. Da ist ein Kommentar der Form "#end of crude doc strings" überflüssig.
- Das "#----------------------------------------" ist reichlich überflüssig, besonders in der ersten Zeile der Datei.
- Warum benutzt du keine Docstrings um den Sinn des Moduls zu beschreiben, sondern Kommentare?
get.py:
- `answer != "yes"` kann man auch freundlicher gestalten: `answer not in ("yes", "y", ...)`
- Die `answer == ` kannst du wieder durch ein Dictionary ersetzen
- Du hast keine Fehlerbehandlung. Wenn jemand keinen Integer eingiebt, dann schmiert das Programm einfach ab
- Ein leeres `return` am Ende einer Funktion ist überflüssig
- Du solltest deine Methoden besser dokumentieren und kommentieren
-
solltest du besser so formulieren:
- Benutze richtige Bezeichner `h` sagt zum Beispiel gar nichts aus.
- `hash` ist eine built-in-Funktion, du solltest daher nichts an diesen Namen binden.
- Ein Parameter mit dem Namen `hash` in der Funktion `hash` ist sehr schlecht gewählt.
- Statt 0 und 1 solltest du `False` und `True` verwenden
- Dateien solltest du mit dem with-Statement öffnen.
- Du vermischt überall Logik mit Eingabe und Ausgabe
- `estimated_archive_size` kann man sicher kürzen, zum Beispiel durch Verwendung von Tupeln und einer Schleife.
- Wenn du einen regulären Ausdruck nur einmal verwendest, dann brauchst du ihn nicht per Hand zu kompilieren
- `page = int((offset + 25) / 25)` denke darüber noch einmal nach
- Wenn `req` die URL nicht öffnen kann wird None zurückgegeben und den Programm bricht ab. Wenn du einen Fehler behandelst, dann musst du dich danach in einem konsistenten Zustand befinden du sorgst jetzt nur dafür, dass es an einer anderen Stelle kracht.
- `convert` kann man viel kürzer schreiben.
- `urlopen` unterstützt sicher auch das with-Statement
syn.py:
- Dateipfade solltest du mit `os.path.join` zusammensetzen
- Benutze keine globalen Variablen wie `db`
- Die Datenbank sollte wohl eher eine Klasse sein und keine Sammlung an Funktionen.
Natürlich gelten die angemerkten Sachen auch in anderen Modulen. Vorallem das with-Statement, das Zusammensetzen von Strings und die Verwendung von Dictionaries.
Es lassen sich noch überall Kleinigkeiten finden, aber bis du die genannten Stellen verbesser hast, hast du sicher genugzu tun.
Sebastian