Re^3: Strukturiertes Programmieren
1. Requirements
Bevor du anfängst, drauf los zu tippen, schreibst du dir mal
auf ein Blatt Papier, was das Programm können soll (noch nicht
wie!), was in Zukunft noch evtl. dazu kommen könnte und so
weiter.
Das weiß ich doch in DEM Stadium noch gar nicht! Das ist ja
das Problem. Also gut, was die Hauptaufgabe sein soll weiß ich
natürlich schon. Aber für detailliertere Überlegungen reicht's
in dem Stadium noch nicht. Außerdem will ich endlich, endlich
mit dem Programmieren anfangen!!!!!!!!! (Seufz - das ist
wieder was für's Psychologieboard...)
Das ist ja der Trick an der Sache. Erst überlegen, was man alles braucht, dann erst anfangen. Es muss ja noch nicht alles festgezurrt werden, du solltest dir aber jetzt schon überlegen, was später noch dazu kommen kann, damit du dieses jetzt schon mit in deine Überlegungen einnimmst, auch wenn du es noch nicht programmierst.
Dazu solltest
du ein paar Prinzipien beachten, z.B. "Information Hiding":
Mache möglichst die Informationen nur da zugänglich, wo du sie
brauchst (Lokale statt globale Variablen). Wenn du eine
Funktion aufrufst, dann sollten alle benötigten Werte über die
Parameter mitgegeben werden und es sollte für die Nutzung egal
sein, wie die Funktion die Werte berechnet. Die Funktion
sollte somit auch Seiteneffektfrei sein, d.h. keine globalen
Variablen ändern, sondern nur über Eingabe- und
Ausgabeparameter Daten ändern.
Warum das? Was spricht gegen globale Variablen?
Gegen globale Variablen spricht, dass man sie überall benutzen und ändern kann und das tut man dann auch und wenn du den Teil dann mal ändern oder erweitern musst, dann musst du den ganzen Quelltext durchsuchen, wo du diese Variable anpackst. Ebenso umgekehrt: Wenn du eine Prozedur hast, in der du globale Variablen liest und änderst, dann hängt das Verhalten dieser Prozedur/Funktion immer von diesen Variablenzuständen ab. Nutzt du aber nur lokale Variablen in der Prozedur und übergibst sonstige benötigten Daten als Parameter, dann hast du eine Funktion, die bei gleicher Eingabe IMMER die gleiche Ausgabe liefert, was die Benutzung dieser Funktion einfacher und übersichtlicher macht.
Dann solltest du zum Beispiel sprechende Variablen- und
Funktionenbezeichner wählen. Wem nützt es etwas, wenn der
Funktionsname nur vier Buchstaben hat, du aber nicht mehr
weisst, was die Funktion void Stgb(a,b) macht. Also schön lang
ausschreiben, was gemeint ist. Zu jeder Programmiersprache
gibt es heute einen Editor mit Syntaxvervollständigung, also
können die Namen auch ruhig 20 Zeichen haben, z.B. in der Form
Programmteil_Funktion_Objekt wie "Datenbank_Suche_Vorname"
usw...
Versuch ich auch schon. Aber diese Namen sagen mir nur im
Moment was! Ein paar Wochen später frage ich mich dann, wie
ich auf diesen schwachsinnigen Namen gekommen bin...
Außerdem denke ich manchmal: so, jetzt probiere ich das mal
mit einer Schleife. Und als Schleifenvariable nehme ich dann
mal 'i' - iss ja eh' nur ein Provisorium. Leider wird aus dem
Provisorium dann ein Stück endgültiger Code, von dem man froh
ist daß er überhaupt läuft. Darum möchte man dann um Himmels
Willen nicht den Variablennamen ändern und somit neue Fehler
in diesem chaotischen Code erzeugen. Wobei natürlich viele
Fehler dann daher kommen, daß der Index wegen einer
nachträglich eingefügten zweiten Schleife 'plötzlich' einen
anderen Inhalt hat. Ach, das macht Freude... :o))
Also meine Schleifenvariablen heissen auch meisst i oder ii. Dies ist auch in Ordnung, da dann jeder weiss, dass es sich um einen Zähler handelt. Wichtiger sind auf jeden Fall Funktionsnamen und Namen von weiteren Variablen, besonders von globalen.
Wichtig ist auf alle Fälle, dass du alle deine Funktionen gut
dokumentierst, nimm dir ein Dokumentationstool zur Hilfe,
welches dir eine Doku für deinen Quelltext erstellt, z.B.
Javadoc(Java) oder Doxygen(C++,VB,..). Dann weisst du auch
nachher noch, wofür eine Funktion gut war und kann leichter
Änderungen integrieren...
Ja, davon hat Dein Mitbeantworter unten (oder war's oben? :o)
) auch schon gesprochen. Davon habe ich noch nie gehört. Was
bringt mir das? Ich finde, das hört sich eher nach MEHR Arbeit
an...
Ist es am Anfang auch. Natürlich ist es mehr Arbeit zu einer Funktion noch einen Kommentar hinzuzuschreiben, aber in ein paar Wochen merkst du dann, dass es schon hilft, wenn man viele Kommentare in den Quelltext schreibt. Und so Tools wie Doxygen dienen einfach dazu, sämtliche Funktionen, Prozeduren und Variablen mit den passenden Kommentaren in lesbare/Ausdruckbare Form zu bringen. Wenn du dann ein paar Wochen später einen neuen Teil hinzufügst, dann kannst du in dieser Liste einfach nachschauen, wie die Prozeduren hiessen, die du benutzen musst, welche Parameter ihr übergeben werden und was sie genau macht. Es geht aber auch ohne Tool wie Doxygen, hauptsache, es steht im Quelltext. Beispiel: Eine Funktion, die einen String auf max x Zeichen kürzt:
' Diese Funktion liefert zu einem gegebenen String den gekürzten String der Länge x zurück.
' Ist der String kürzer als x, wird er nicht gekürzt
' Der originalstring wird nicht verändert, es wird nur eine Kopie zurückgegeben
' x muss größer als Null sein
'
function crop_string(byval originalstr as string, byval maxlen as integer) as string
crop_string = left(originalstr,maxlen)
end function
as reicht schon. Ohne den Quelltext der Funktion zu lesen (der momentan recht kurz ist, aber natürlich viel länger sein kann), siehst du im Kommentar darüber was die Funktion macht und wie sie benutzt werden kann.
PS:
Ist diese prozedurale Programmierung, die Du so propagierst,
nicht eine Vorstufe der OO-Programmierung? Die hat mich bei
Excel bzw. VBA schon an meine Grenzen gebracht. Jetzt versuch'
ich das grad unter VB.NET zu checken. Von dem was ich kapier:
klingt ja irre. Das verbessert die Struktur eines Programmes
ja nochmal erheblich. Wobei mich diese ellenlangen Ausdrücke
wie
Workbooks("xyz.xls").Worksheets("Tabelle1").cells(intZeilenindex,
intSpaltenindex) am Anfang auch abgeschreckt haben... Oder -
eigentlich tun sie das immer noch.
Nein, Nein. Prozedurale Programmiersprache ist einfach eine Sprache die Prozeduren hat und diese Schachteln kann. VBA ist da eher so ein Zwischending, da VBA Teile von prozeduralen, funktionalen und große Teile von Objektorientierten Sprachen hat (Das Workbook ist nämlich z.B. ein Objekt, auch wenn du es nicht weisst ;-).
Diese Bandwürmer w("dsf").b("sdf").c(4).d kannst du mit with abkürzen, alsowith w("dsf").b("sdf")
.c(4).d=2
.c(5).d=4
end with
Grüße Ralph
