Ist schon ei bisschen her seitdem ich es programmiert habe.
Man könnte die das Eingabeformular noch in eine eigene Funktion packen.
Aber dazu bin ich aktuell zu faul.
Hier ist der Code: Adressbuch Version 2.4
Adressbuch
-
python_freak
- User
- Beiträge: 16
- Registriert: Sonntag 22. August 2010, 09:06
- Wohnort: Mein Zimmer
- Kontaktdaten:
Hier habe ich mal ein kleines Adressbuchprogramm.
Ist schon ei bisschen her seitdem ich es programmiert habe.
Man könnte die das Eingabeformular noch in eine eigene Funktion packen.
Aber dazu bin ich aktuell zu faul.
Hier ist der Code: Adressbuch Version 2.4
Ist schon ei bisschen her seitdem ich es programmiert habe.
Man könnte die das Eingabeformular noch in eine eigene Funktion packen.
Aber dazu bin ich aktuell zu faul.
Hier ist der Code: Adressbuch Version 2.4
-
deets
Hier genauso wie bei NickyPad: du solltest dich mal mit der Moeglichkeit, ueber Dateien und Listen zu iterieren beschaeftigen. Und nicht ueber while-schleifen mit explizitem inkrement auf Listenelemente zugreifen.
-
BlackJack
@python_freak: Die Kommentare bei den Importen sind überflüssig. Ein Kommentar sollte einen Mehrwert bieten und nicht noch einmal das absolut offensichtliche aus dem Quelltext wiederholen.
Sternchenimport sollte man vermeiden, weil man sich damit alle Namen auf dem importierten Modul in den Namensraum des importierenden Moduls holt, ob man die nun verwendet oder nicht und bei Modulen mit vielen Namen immer mit der Gefahr von Namenskollisionen verbunden.
`os.path` braucht man nicht importieren, wenn man schon `os` importiert hat.
Sich wiederholende Werte wie Pfade sollte man *einmal* an einen Namen binden und nicht mehrfach in den Quelltext schreiben. Der Pfad, den Du da vorgibst, der funktioniert so nur unter Windows vernünftig.
Wenn man ein ``if``/``else`` hat, wo in einem Zweig nur ein ``pass`` steht, dann kann man das auch nur mit einem ``if`` ausdrücken.
Die ``os.chdir()`-Funktion sollte man vermeiden, weil sie einen globalen Zustand des Prozesses verändert. Darüber sollte man so wenig wie möglich Annahmen treffen um Probleme zu vermeiden und besser auf absolute Pfade oder relative zum initialen Arbeitsverzeichnis setzen.
Warum heisst eine Klasse die eine Person darstellt `Adressbuch`? Beziehungsweise warum steht an einer Klasse die `Adressbuch` heisst, dass sie eine Person darstellen würde? Das passt nicht zusammen.
Deine Mischung aus Klasse und ``global`` ist fast noch schlimmer als ``global`` es ohne Klasse in Funktionen wäre. Wenn man das ordentlich in Klassen organisiert, dann braucht man die ``global``-Anweisung nicht. Oder anders herum: solange Du ``global`` verwendest, stimmt der Programmentwurf nicht.
`funktion` ist für ein `Tkinter.Tk`-Objekt ein total unpassender Name.
Innerhalb von Methoden, sollte man genau wie bei Funktionen, nicht auf Objekte auf Modulebene zugreifen, die keine Konstanten sind. Die Methoden von `Adressbuch` sollten also nicht auf den Namen `a` zugreifen. Der sollte auf Modulebene gar nicht existieren. Und ausserdem ist es ein schlechter, weil total nichtssagender Name.
Der Ausdruck ``u'.data'.encode(stdout_encoding)`` ist sinnfrei. Ein einfaches '.data' hätte es hier auch getan, denn Bytestrings, die nur ASCII-Zeichen enthalten, kann Python zur Not immer in ein `unicode`-Objekt umwandeln.
Dateinamen mit einer Endung suchen, geht auch sehr gut mit dem `glob`-Modul.
Bei ``lambda:a.weiter("3")`` ist die ``"3"`` nicht wirklich offensichtlich. Wenn Du ”irgendetwas” beziehungsweise ”Nichts” übergeben willst, dann nimm wenigstens `None`. Und am besten nicht beim Aufruf, sondern als Default-Argument bei der Methode.
Die erste ``while``-Schleife in `weiter()` ist viel zu kompliziert. Das sollte einfach eine ``for``-Schleife über die Dateien sein. Wobei die irgendwie wieder aus dem ”nichts” zu kommen scheinen. Das ist alles sehr verworren. Insbesondere dann auch der weitere Programmablauf wo anscheinend rekursiv die `main()`-Funktion aufgerufen wird. Das kommt innerhalb des Programms mehrfach vor und ist eine total kaputte Ablaufsteuerung. Das geht nicht unbegrenzt gut, weil dadurch der Aufrufstapelspeicher immer weiter zugemüllt wird, bis das Programm mit einer Fehlermeldung aus steigt.
Das ständige zerstören und neu erstellen von `Tk`-Objekten ist zumindest ungewöhnlich und zusammen mit der wirren Ablaufsteuerung wäre ich mir auch nicht sicher, dass sichergestellt ist, dass es immer nur *ein* `Tk`-Exemplar gleichzeitig gibt.
Sternchenimport sollte man vermeiden, weil man sich damit alle Namen auf dem importierten Modul in den Namensraum des importierenden Moduls holt, ob man die nun verwendet oder nicht und bei Modulen mit vielen Namen immer mit der Gefahr von Namenskollisionen verbunden.
`os.path` braucht man nicht importieren, wenn man schon `os` importiert hat.
Sich wiederholende Werte wie Pfade sollte man *einmal* an einen Namen binden und nicht mehrfach in den Quelltext schreiben. Der Pfad, den Du da vorgibst, der funktioniert so nur unter Windows vernünftig.
Wenn man ein ``if``/``else`` hat, wo in einem Zweig nur ein ``pass`` steht, dann kann man das auch nur mit einem ``if`` ausdrücken.
Die ``os.chdir()`-Funktion sollte man vermeiden, weil sie einen globalen Zustand des Prozesses verändert. Darüber sollte man so wenig wie möglich Annahmen treffen um Probleme zu vermeiden und besser auf absolute Pfade oder relative zum initialen Arbeitsverzeichnis setzen.
Warum heisst eine Klasse die eine Person darstellt `Adressbuch`? Beziehungsweise warum steht an einer Klasse die `Adressbuch` heisst, dass sie eine Person darstellen würde? Das passt nicht zusammen.
Deine Mischung aus Klasse und ``global`` ist fast noch schlimmer als ``global`` es ohne Klasse in Funktionen wäre. Wenn man das ordentlich in Klassen organisiert, dann braucht man die ``global``-Anweisung nicht. Oder anders herum: solange Du ``global`` verwendest, stimmt der Programmentwurf nicht.
`funktion` ist für ein `Tkinter.Tk`-Objekt ein total unpassender Name.
Innerhalb von Methoden, sollte man genau wie bei Funktionen, nicht auf Objekte auf Modulebene zugreifen, die keine Konstanten sind. Die Methoden von `Adressbuch` sollten also nicht auf den Namen `a` zugreifen. Der sollte auf Modulebene gar nicht existieren. Und ausserdem ist es ein schlechter, weil total nichtssagender Name.
Der Ausdruck ``u'.data'.encode(stdout_encoding)`` ist sinnfrei. Ein einfaches '.data' hätte es hier auch getan, denn Bytestrings, die nur ASCII-Zeichen enthalten, kann Python zur Not immer in ein `unicode`-Objekt umwandeln.
Dateinamen mit einer Endung suchen, geht auch sehr gut mit dem `glob`-Modul.
Bei ``lambda:a.weiter("3")`` ist die ``"3"`` nicht wirklich offensichtlich. Wenn Du ”irgendetwas” beziehungsweise ”Nichts” übergeben willst, dann nimm wenigstens `None`. Und am besten nicht beim Aufruf, sondern als Default-Argument bei der Methode.
Die erste ``while``-Schleife in `weiter()` ist viel zu kompliziert. Das sollte einfach eine ``for``-Schleife über die Dateien sein. Wobei die irgendwie wieder aus dem ”nichts” zu kommen scheinen. Das ist alles sehr verworren. Insbesondere dann auch der weitere Programmablauf wo anscheinend rekursiv die `main()`-Funktion aufgerufen wird. Das kommt innerhalb des Programms mehrfach vor und ist eine total kaputte Ablaufsteuerung. Das geht nicht unbegrenzt gut, weil dadurch der Aufrufstapelspeicher immer weiter zugemüllt wird, bis das Programm mit einer Fehlermeldung aus steigt.
Das ständige zerstören und neu erstellen von `Tk`-Objekten ist zumindest ungewöhnlich und zusammen mit der wirren Ablaufsteuerung wäre ich mir auch nicht sicher, dass sichergestellt ist, dass es immer nur *ein* `Tk`-Exemplar gleichzeitig gibt.
-
python_freak
- User
- Beiträge: 16
- Registriert: Sonntag 22. August 2010, 09:06
- Wohnort: Mein Zimmer
- Kontaktdaten:
ok...