Bei der Software Entwicklung sollte man nie direkt loslegen zu programmieren!

Typischer Ablauf, auch wenn in einfachen Fällen stark verkürzt:

1. Requirement Engineering
2. Design
3. Implementation
4. Testing

Wichtige Prinzipien:

• Eine Komponente hat genau eine Aufgabe
• hierarchisches Denken, von Abstrakt zu Konkret
• One Level of Abstraction

Ein PC ist dumm. Er kann maximal so intelligent werden, wie sein Programmierer.

Ein PC kann nicht abschätzen, nicht annehmen, nicht vermuten. Entweder man sagt ihm genau was Sache ist oder er baut Scheiße

Wenn du in Gedanken etwas So ungefähr oder So in etwa hast, kann der PC damit noch nichts anfangen. Er braucht Genau so.

Das folgt eigentlich aus vorigem Punkt: Die Penibilität muss sich auch im geschriebenem Wort (egal ob Anforderung oder Code) wiederfinden. Die Suche nach geeigneten Namen ist manchmal nicht trivial, dabei sollte man aber dennoch nicht aus Frust das erst-beste nehmen.

Aber das geschriebene Wort muss auch für jeden zukünftigen Leser (inkl. dir selbst) in sich klar sein. Er muss es überschauen und vom Grund her schnell verstehen können.

Hilfreiche Handlungsempfehlungen:

• Sprechende Namen von Variablen und Methoden
• kaum Abkürzungen
• kurze Methoden
• kleine Klassen

Oder anders ausgedrückt:

Klingt vielleicht eher abschreckend und wird einem nicht unbedingt sofort klar, es hilft aber enorm:

Prinzipien kamen bereits und werden immer wieder auftauchen. Sie helfen einem Fehler vorzubeugen und, wenn die Prinzipien wirklich eingeschliffen sind, schneller zu gutem Code zu kommen.

Je nach Bereich in dem man sich bewegt sind andere wichtig. Was eigentlich durchweg immer gilt:

• Single Responsibility
• KISS: Keep it simple, stupid
• CSE30 (Bitte ANR: HALTET EUREN SCHEIß KONSISTENT)

Kurze, knappe Beschreibung wofür man das Ganze macht. Bei größeren Systemen ist esdurchaus möglich, dass es mehr als 1 gibt - bei kleinen Helferlein wie Makros am besten Unix-Regel befolgen:

one task one process

ein Tool pro Aufgabe

Was muss bei der Umsetzung beachtet werden?

• technisch:
  • Programmiersprache
  • Framework
  • Environment
• organisatorisch:
  • wo liegen die Daten?
  • wohin mit Ergebnissen
• fachlich:
  • math. Algorithmen?
  • fachliche Hintergründe und Regelwerke

In größeren Systemen müssen noch die beteiligten Akteure sowie die Stakeholder berücksichtigt werden.

Eine Beschreibung bzw. Definition der Objekte und deren Attribute mit denen innerhalb des Systems gearbeitet wird. Primär sollte man sich auf die fachlichen Datenobjekte konzentrieren, sowie deren Beziehung untereinander. Aber auch die systembedingten (z.B. Konfiguration) sollten durchdacht sein.

Beschreibung dessen, was denn wirklich zu tun ist, um das Ziel zu erreichen.

Möglichst nicht in Prosa sondern kurz, klar, strukturiert. Möglichkeiten sind Diagramme (z.B. UML) oder Use Cases.

Prosa birgt durch Worte und Begriffe wie oder, wie, in etwa oder analog zu durchaus mehr Potential zu Zweideutigkeiten und Missverständnissen als man zuerst glauben mag.

Dabei sollte man nicht einen einzigen, vollständig ausdetailierten Prozess beschreiben, sondern hierarchisch vorgehen. Ein Prozess besteht aus um die 7 Schritte von denen jeder wieder als Unterprozess ausdetailiert werden kann.

Innerhalb eines Prozess sollte jeder Schritt auf dem gleichen Abstraktionslevel liegen.

Man nimmt die erarbeiteten Anforderungen und guckt welche Teile man also im System brauchen wird um die gewünschte/beschriebene fachliche Lösung technisch wirklich umsetzen zu können.

Dabei sollte man so viel wiederverwerten, verallgemeinern und vereinheitlichen wie möglich - ohne natürlich die endgültige Lösung fachlich zu verändern.

Man geht hierarchisch dabei vor und baut erstmal größere Blöcke, die zu weiteren, kleineren, spezifischeren Blöcken dekomponiert werden.

Dabei sollte immer gelten:

• Information Hiding
• Single Responsibility & Separation of Concern
• One Level of Abstraction

Design Patterns sind Strukturen und Mechansismen, die sich bewährt haben um bestimmte, wiederkehrende Problemstellungen zu Lösen. Dabei sind Design Patterns mehr eine Lösungsschablone denn die fertig ausgearbeitete Musterlösung.

Zumindest einige, grundlegende sollte man im groben kennen - ähnlicher Hintergrund wir bei den Prinzipien:

Eines der wohl bekanntesten Bücher dazu: Gang of Four, Design Patterns

In jeder Programmiersprache gibt es verschiedene Typen an Daten mit denen man arbeitet. Von den ganz konkreten Ja/Nein, Zahl und Text über abstrakteren wie Menge/Liste zu ganz abstrakten. Wie die Typen heißen und welche Untertypen (Ganze Zahlen, reelle Zahlen, ...) es gibt hängt von der jeweiligen Programmiersprache ab.

Je nach Typ kann man andere mathemathische, vergleichende oder logische Operationen durchführen. Eine Text kann man zum Beispiel nicht dividieren, bei einer Zahl nicht Buchstaben anfügen.

Native Typen in VBA:

• Ja/Nein: Boolean
• ganze Zahlen: Byte, Integer, Long
• reelle Zahlen: Single, Double, Decimal
• Text: String
• Datum: Date
• Währung: Currency

Um mit einem Wert, der einen bestimmten Typ hat, besser im Programm arbeiten zu können weist man den üblicherweise einer Variable zu. Die Variable kann wie der Wert an sich verwendet werden, der Variable kann aber auch im weiteren Verlauf ein neuer Wert zugewiesen werden.

In vielen Programmiersprachen ist eine Variable einem Typ fest zugeordnet, sprich es können der Variable nur Werte dieses Typs zugewiesen werden (statische Typisierung). Anderen Sprachen können Werte beliebigen Typs der gleichen Variable zugewiesen werden (dynamische Typisierung). VB ist primär dynamisch Typisiert, man kann aber auch eine statische Festlegung einer Variable erzwingen.

In VB erfolgt die übliche, dynamische Deklaration wie folgt:

	Dim nameDerVariable
			

Eine statische Deklaration wäre:

	Dim nameDerVariable As TypDerVariable
			

Eine Deklaration einer Liste (Array) von Typen wäre:

	Dim nameDesArrays(anzahlDerElemente) As TypDerElemente
			

Üblicherweise unterscheidet man dabei zwischen dem Erzeugen einer Variable (Deklaration) und der Zuweisung eines Werts zur Variable (Definition). In einigen Programmiersprachen wird eine Variable implizit deklariert sobald sie das erste mal definiert wird. Häufig können (explizite) Deklaration und Definition in einem Schritt erfolgen.

Das implizite deklarieren hat Vorteile, da man währnd des Programmierens nicht erst drüber nachdenken muss, welche Variablen man denn nun alle braucht und sind die schon deklariert oder muss dies noch erfolgen. Dadurch kann man also schneller Code runterschreiben. Allerdings hat dieses Verhalten auch Nachteile - zum einen was die effizienz von Code angeht aber es kann auch die Fehlersuche schwerer machen. Wird nämlich aus Versehen eine Variable falsch geschrieben (Zeichendreher oder ähnliches), so muss man sehr genau hinschauen wo man die Variable wie geschrieben hat. Bei explizit notwendiger Deklaration weist einen der Compiler/Interpreter darauf hin, wenn eine Variable (die falsch geschriebene) das erste mal genutzt wird. Man wird also direkt darauf gestoßen, dass da etwas nicht stimmt.

Eine (einfache) Variable wird definiert via:

	nameDerVariable = wertDerVariable
			

In bestimmten Sonderfällen kommt folgende Variante zum Einsatz (später mehr):

	Set nameDerVariable = wertDerVariable
			

Um in VB zu erzwingen, dass alle Variablen explizit deklariert werden müssen kann folgende Befehl zu Beginn des Moduls verwendet werden:

	Option Explicit
			

Ein Kommentar ist ein beliebiger Text der vom Compiler/Interpreter vollkommen ignoriert wird und für den menschlichen Leser des Codes gedacht ist.

Kommentare sind ein gutes Hilfsmittel um deutlich zu machen was im Code vor sich geht, aber auch dieses Hilfsmittel hat auch negative Seiten:

• Es verleitet dazu den Code nicht ganz so sauber zu programmieren, da man ja über einen Kommentar beschreiben kann, was er macht
• Code und Kommentar können sich im Laufe der Zeit auseinanderleben, das heißt der Code wird angepasst an neue Bedingungen/Situationen aber der Kommentar vergessen. Und dadurch passt der Code nicht mehr zum Kommentar bzw. schlimmstenfalls verleitet der Kommentar den Programmierer den Code falsch zu verstehen.

Aus beiden Gründen ist meine persönliche Empfehlung:

In VB werden Kommentare über das Apostroph eingeleitet und gehen bis zum Ende der Zeile.

	doSomething 'alles hier ist Kommentar
			

Schleifen bieten die Möglichkeit bestimmte Schritte mehrfach auszuführen. Zusammen mit if/select bieten sie die fundamentale Basis zum Steuern des Programmflusses.

Grundsätzlich besteht jede Schleife aus einer Bedingung und einem Schleifenkörper. Die Bedingung bestimmt, ob die Schleife durchgeführt wird und der Schleifenkörper ist, was bei erfüllter Bedingung durchgeführt wird.

Ein Schleifendurchgang wird oft auch als Iteration und das Durchlaufen einer Schleife als iterieren bezeichnet.

Es gibt verschiedene Arten von Schleifen die sich für bestimmte Szenarien besser oder schlechter eignen.

	Do While ausdruck
		...  
	Loop
				

	Do Until ausdruck
		...
	Loop
				

	Do 
		...  
	Loop While ausdruck
				

	Do
		...
	Loop Until ausdruck
				

	For zähler = 1 To X
		...
	Next
				

	For ziffer = 2 To 8 Step 2
		...
	Next
				

	For rest = 10 To 0 Step -1
		...
	Next
				

	For Each zähler In aufzählung
		...
	Next
				

Eine Methode muss, wie Variablen auch, deklariert und definiert werden. Eine explizite Deklaration ohne direkte Definition passiert in nur noch wenig Programmiersprachen. Meist wird beides gemeinsam durchgeführt.

Bei der Deklaration wird der Name, die Parameter und (in statisch typisierten Programmiersprachen) der Typ des Rückgabewertes angegeben. In statisch typisierten Sprachen ist der Typ des Rückgabewertes von Methoden die nichts zurückgeben meist void oder nil, was beides im Grunde Das Nichts bedeutet.

In VB muss man unterscheiden, ob die Methode einen Rückgabewert hat oder nicht. Methoden ohne Rückgabewert werden als Sub-Routinen bezeichnet und wie folgt deklariert und definiert:

	Sub methodenName(Parameter1, Parameter2)
		...
	End Sub
			

Methoden, die einen Rückgabewert haben werden als Funktionen bezeichnet und wie folgt deklariert undd definiert:

	Function methodenName(Parameter1, Parameter2)
		...
		methodenName = wertOderVariable
	End Function
			

Der Rückgabewert wird festgelegt, in dem man einer (magischen) Variable mit dem gleichen Name wie der Methode einen Wert zuweist.

Optional kann man, wie bei der Variablendeklaration auch bei der Methodendeklaration einen Typ festlegen, den Typ des Rückgabewertes:

	Function methodenName(Parameter1 As TypDesParameter, Parameter2 As TypDesParameter) As TypDesRückgabeWertey
		...
		methodenName = wertOderVariable
	End Function
			

Eine Reihe von Programmiersprachen unterstützen das sogenannte überladen einer Methode. Das heißt es gibt die gleiche Methode (des Namens nach) in mehreren, spezialisierten Varianten, je nach dem welche und wieviele Parameter übergeben werden. Dabei kann sich auch der Rückgabetyp von einer Methodenvariante zur anderen unterscheiden.

In immer mehr Programmiersprachen können Parameter als optional deklariert werden. Das heißt, wenn beim Aufruf der Methode kein Wert für diesen Parameter benannt wird, so wird ein, bei der Deklaration festgelegter, Standardwert genommen.

Üblicherweise müssen die optionalen Parameter hinten in der Parameterliste auftauchen, also es darf kein benötigter Parameter hinter einem optionalen Auftauchen.

In VB werden optionale Parameter wie folgt deklariert:

	Sub methodenName(Parameter1, Optional Parameter2 As TypDesParameter = StandardwertDesParameter)
		...
	End Sub
			

Eine Methode wird über ihren Namen aufgerufen, danach folgen die Parameter die man der Methode mitgeben will. Im Grunde alle weithin bekannten Programmiersprachen kapseln dabei die Parameter in Klammern ein, was die Übersicht erhöht sobald die Aufrufe ein wenig komplizierter werden. Eine Reihe Programmiersprachen bieten dabei an die Klammern wegzulassen, solange der Ausdruck dadurch eindeutig bleibt.

VB ist ein wenig anders. Um Methoden aufzurufen (ohne an deren Rückgabewert interessiert zu sein) darf man keine Klammern um die Parameter schreiben:

	methodenName
	methodenName parameter1, parameter2
			

Ist man aber an dessen Rückgabewert, in welchem Kontext auch immer, muss man die Parameter einklammern:

	variablenName = methodenName()
	if methodenName(parameter1, parameter2) then ...
			

Man kann VB dazu bringen auch bei einfachen Methodenaufrufen Klammern zu erwarten, in dem man dem Methodenaufruf call voranstellt:

	call methodenName()
			

Als Parameter einer Methode kann natürlich der Rückgabewert einer anderen genommen werden:

	methode1 parameter1VonMethode1, methode2(parameterVonMethode2)
			

Möchte man einen optionalen Parameter überspringen, den darauffolgenden optionalen Parameter aber setzen, so lässt man den Wert des zu überspringenden Parameters weg, schreibt aber das Komma um anzuzeigen, dass nun der nächste Parameter definiert wird:

	methodenName parameter1, , parameter3
			

Eine Rekursion ist, wenn eine Methode sich selber aufruft. Dies kann in manchen Fällen enorm praktisch sein, allerdings muss man genau aufpassen, dass sich dadurch keine Endlosschleife bildet. Man braucht also ein Abbruchkriterium welches innerhalb der Methode geprüft wird.

Ein bekanntes Beispiel ist die Berechnung von Fibunacci-Zahlen:

	Function fib(zahl As Integer) As Integer
		if zahl == 0 'Abbruchkriterium
			fib = 1
		elsif zahl == 1 'Abbruchkriterium
			fib = 1
		else
			fib = fib(zahl - 1) + fib(zahl - 2) 'Rekursion
		end
	End Function
			

Es gibt zwei Arten wie Parameter an eine Methode übergeben werden können:

• ByVal: Es wird der Wert der Variable genommen, kopiert und der Methode als ein Parameter übergeben
• ByRef: Es wird eine Referenz auf die Variable selber der Methode als Parameter übergeben

In VB macht es für die Benutzung keinen Unterschied, ob ein Parameter ByVal oder ByRef ist. Aber es ergeben sich dadurch unterschiedliche Möglichkeiten aber auch potentielle Schwierigkeiten.

ByVal-Variablen kann man nach belieben innerhalb der aufgerufenen Methode ändern und verarbeite. Keine dieser Änderungen ist außerhalb dieser Methode sichtbar, da die Methode eben eine Kopie des Wertes als Parameter erhalten hat.

Dahingegen ist jegliche Änderung an einer ByRef-Variable die in einer aufgerufenen Methode durchgeführt wird auch der aufrufenden Methode sichtbar, da die Variable selber an die Methode übergeben wird.

	Sub foo(ByRef fubar As Integer)
		fubar = fubar + 5
	End Sub
	
	Sub bar()
		Dim beliebigeVariable As Integer
		beliebigeVariable = 3

		foo beliebigeVariable
	
		MsgBox (beliebigeVariable) ' zeigt an: "8"
	End Sub
			

Man kann einer Methode eine sogenannte Sichtbarkeit mitgeben. Dies hat einen Einfluss darauf, von welchen anderen Methoden und Modulen diese Methode aufgerufen werden darf. Es gibt drei Werte:

• Public: Diese Methode darf von überall aufgerufen werden
• Friend: Diese Methode darf von jeglichem Code des gleichen Dokuments aufgerufen werden
• Private: Diese Methode darf nur innerhalb des gleichen Moduls aufgerufen werden.

Durch die Möglichkeit private Methoden zu deklarieren kann man Helfermethoden innerhalb eines Moduls erschaffen, die häufig genutzte Arbeitsschritte einmalig bereitstellen, die dann von den anderen Methoden in diesem Modul verwendet werden können. Gleichzeitig stehen nach außen (also den anderen Modulen) nur die öffentlichen Methoden zur Benutzung, die die Hauptaufgaben ausführen.

Deklariert man innerhalb eines Moduls, aber außerhalb einer Methode, Variablen, so stehen diese allen Methoden des Moduls zur Verfügung. Damit kann man zum Beispiel zentrale Konfigurationen für dieses Modul ablegen, oder aber Werte uber eine Methode berechnen lassen und über eine andere Methode abfragen.

Analog zu den Methoden in einem Modul könne auch Modulvariablen als Public oder Private deklariert werden.

Der wahre Nutzen von Modulen, und allen anderen Mitteln zur Strukturierung von Code, erschließt sich meist erst in der Praxis im Laufe der Zeit. Sobald der eigene Code so lang geworden ist, dass man sich nicht mehr zurecht findet oder man kaum was wiederverwenden kann, weil es so viele Querverbindungen von einer Methode zu den andern gibt spielen Module als Gegenentwurf ihre Stärke aus. Mein Rat ist deshalb einfach immer über Module nachzudenken - man lernt sie mit der Zeit schätzen.