[Python-de] Schoene Programme gesucht

Stefan Schwarzer sschwarzer at sschwarzer.net
Sam Mar 13 15:37:25 CET 2004


Hallo Matthias,

(ich wollte die Mail zuerst wegen evtl. zu "werblichen Charakters"
(s. u.) nicht an die Liste schicken, aber ich denke, dass einige
sinnvolle Dinge drinstehen, die ich der Liste nicht vorenthalten will
:-) )

Ich bin mir darüber im Klaren, dass es neben den unten stehenden
Ansätzen/Erfahrungen auch noch andere gibt (= YMMV).

On Fri, 2004-03-12 20:21:42 +0100, Matthias Kluwe wrote:
> Ich habe das erste Kapitel gerade gelesen und konnte immerhin schon zwei
> Shortcuts zur Anwendung bringen. Das war zwar ganz nett, hat mich aber
> nicht grundsätzlich weiter gebracht. Vielleicht habe ich ja mal
> Gelegenheit, in den Rest des Buches reinzuschnuppern.
> 
> Davon mal abgesehen geht es mir jedoch eher um die Organisation größerer
> Mengen Programmtext, als sie normalerweise in einem Buch abgedruckt
> sind. Vielleicht traut sich ja ein Entwickler hier, auf sein eigenes
> Programm als Gutes Beispiel hinzuweisen.

Ok, ich trau mich mal ;-) Du kannst dir ftputil
( http://www.sschwarzer.net/download/ftputil-2.0.1.tar.gz ) anschauen.
Sag' mir mal, ob du das übersichtlich/verständlich findest. :-) (Ok,
der Testcode ist vielleicht nicht so übersichtlich. ;-) ) Der andere
Code auf meiner Website ist z. T. deutlich älter und m. E. teilweise
weniger gut "designt".

In meinem Buch "Workshop Python"
( http://www.sschwarzer.net/python/workshop_python.html ) gibt es
ebenfalls einige Beispiele, die ausführlicher sind, als die meisten
Übungsaufgaben, die man in Büchern findet. Zu vielen Code-Teilen ist
erklärt, warum derjenige Ansatz gewählt wurde (gegenüber Vor- und
Nachteilen anderer Ansätze). Die Erklärungen zu den Programmbeispielen
im Buch sind ausführlicher, als man sie normalerweise im Code
schreibt, aber du kannst selbst entscheiden, wieviel Informationen du
in deinem Code unterbringst.

Mir ist immer wichtig, so zu schreiben, dass auch andere den Code
lesen und verstehen können. (Das sollte wohl selbstverständlich sein,
aber ist oft nicht so.) Der Nachteil an "zu vielen" Kommentaren kann
sein, dass man den Code ändert, aber die Anpassung der Kommentare
vergisst. Kommentare, die nicht zum Code passen, können sehr(!)
irritierend sein.

Du kannst dieses Risiko etwas verringern, indem du deine Kommentare
"im Code unterbringst". Damit meine ich: Wähle beschreibende
Bezeichnernamen, die dir einige Kommentare ersparen können (weil man
sich schon anhand der Bezeichernamen vorstellen kann, was der Code
macht). Dieses Mittel wird unhandlich, wenn die Bezeichner so lang
werden, dass man dauernd Anweisungen über mehrere Zeilen verteilen
muss. ;-)

Eine Variante des obigen Tipps ist, komplexere Ausdrücke in kürzere zu
zerlegen, wobei für jeden Teilausdruck ein aussagekräftiger Name
verwendet wird.

Was ich normalerweise vermeide, sind Abkürzungen als Bezeichner,
außer sehr gebräuchlichen wie "attr" statt "attribute". Hier ist die
Abkürzung vielleicht sogar lesbarer, weil vertrauter. Gegen
Abkürzungen spricht, dass sie weniger verständlich sind (bzw. man mehr
Code lesen muss, um zu verstehen, worum es geht); außerdem kann es
lästig sein, wenn man beim Schreiben in Modul y überlegen muss, wie
man den Bezeichner in Modul x abgekürzt hat. ;-)

Viele Grüße
 Stefan