Sonderkapitel: Stil

9.1 Blöcke:
9.1.1 Einrücken von Anweisungen
Ein wichtiges stilistisches Merkmal beim Programmieren ist das Einrücken von Anweisungen. Es verbessert Übersichtlichkeit und macht direkt darauf aufmerksam, dass der Programmierer gut ist. In NIKI sind so genannte blanc spaces für die Programmausführung trivial. Daher kann man sie setzen, so oft man will. Jedoch ist es sinnvoller, wenn man gezieltes einrücken beherrscht. Am sinnvollsten ist das Einrücken in Blöcken. Ein Block wird (meistens) mit BEGIN eingeleitet und endet mit END. Alles, was dazwischen steht, wird eingerückt, d.h. die Zeile wird mit einem oder wahlweise zwei Leerzeichen (mehr) begonnen. Ein Beispiel:

PROCEDURE einruecken;
BEGIN
 vor;
 vor;
 vor;
END;

Die Anweisungen sind alle um ein Leerzeichen eingerückt. Natürlich kann es auch vorkommen, dass ein Block in einem anderen enthalten ist. Das nennt man dann eine Verschachtelung. So ist es z.B. möglich, dass eine IF-Anweisung in einer Prozedur steht. Auch hier wird weiter eingerückt, also verschachtelt:

PROCEDURE verschachteln;
BEGIN
 vor;
 vor;
 IF vorne_frei THEN
 BEGIN
  vor;
  drehe_links;
  vor;
 END;
END;

In diesem Beispiel ist ein Block in einem übergeordneten Block verschachtelt. Auch hier wird er wieder mit BEGIN und END eingeschlossen. Sinnvollerweise wurden die drei Anweisungen in der IF-Abfrage ein weiteres Leerzeichen eingerückt.
Angenommen, wir würden die beiden Prozeduren hintereinander deklarieren. Wäre es dann übersichtlicher, wenn wir direkt die eine an die andere schreiben? Auf keinen Fall!!! Dazwischen sollte man immer eine Leerzeile einfügen, also etwa so:

PROCEDURE einruecken;
BEGIN
 vor;
 vor;
 vor;
END;

PROCEDURE verschachteln;
BEGIN
 vor;
 vor;
 IF vorne_frei THEN
 BEGIN
  vor;
  drehe_links;
  vor;
 END;
END;

Man erkennt sofort, wo die eine Prozedur endet und die andere anfängt. Das hilft insbesondere dann, wenn man eine Prozedur suchen muss. So erkennt man sie direkt ohne Probleme.

9.1.2 Sinn von Blöcken:
Wie wir eben gesehen haben, verhelfen Blöcke zur Übersichtlichkeit. Alleine das Einrücken lockert den Quellcode auf. Die Zeilen, die man zwischen zwei Prozeduren frei lässt, helfen beim Suchen. Hätten wir keinen Wert darauf gelegt, Blöcke zu nutzen, hätten wir in etwa das hier:

PROCEDURE einruecken;
BEGIN
vor;
vor;
vor;
END;
PROCEDURE verschachteln;
BEGIN
vor;
vor;
IF vorne_frei THEN
BEGIN
vor;
drehe_links;
vor;
END;
END;

Gut, Geschmäcker sind verschieden, aber hier findet man sich doch nicht mehr zurecht! Und es sind ja nur zwei Prozeduren! Was, wenn man mal 15 deklarieren will? Der Quellcode würde zum Monstrum, das seines Gleichen sucht! Daher sollte man sich immer bewusst machen, dass Blöcke uns helfen und nicht stören sollen.

9.1.3 Kommentare für Blöcke
Wie wir schon im Sonderkapitel 8 gelernt haben (oder hätten lernen sollen), sind Kommentare äußerst nützlich. Aber es stellt sich doch die Frage, ob eine Kommentargebung wie folgt sinnvoll ist:

PROCEDURE kommentare;
BEGIN
 vor;    { geht 1 nach vorne }
 drehe_rechts;    { dreht 3x nach links }
 drehe_um;    { drehe 2x nach links }
END;

Und die Antwort: NEIN! Es würde der Kommentar { geht nach vorne und dreht sich dann nach links } völlig reichen. Und dieser Kommentar kann dann auch hinter den Prozedurnamen, damit man sofort sieht, was NIKI vorhat. Also das Beispiel von oben:

PROCEDURE kommentare;    { geht nach vorne und dreht sich dann nach links }
BEGIN
 vor;
 drehe_rechts;
 drehe_um;
END;

Und schon ist der Quellcode gerettet!

9.2 Groß- und Kleinschreibung:
9.2.1 Groß- und Kleinschreibung als Stil?
Die Frage, ob Groß- und Kleinschreibung wirklich als stilistisches Mittel angesehen werden kann, ist beim programmieren oft nicht wirklich relevant. Viele Programmierer achten auf Groß- und Kleinschreibung, andere nicht. Jedoch erhöht auch das die Übersichtlichkeit um ein Vielfaches. In den Beispielen oben habe ich ja bereits auf Groß- und Kleinschreibung geachtet. Wir unterscheiden dadurch einfacher zwischen Befehlen und reservierten Begriffen. Aber was wird denn nun groß bzw. klein geschrieben?

9.2.2 Was wird groß und was wird klein geschrieben?
Prinzipiell werden folgende Wort komplett groß geschrieben:

PROGRAM
PROCEDURE
BEGIN
END
IF
THEN
ELSE
WHILE
DO
REPEAT
UNTIL

Alles andere sollte immer komplett klein geschrieben werden. Auch Programm- oder Prozedurnamen werden i.d.R. nur klein geschrieben. Setzen sie sich aus mehreren Worten zusammen, nutzt man Unterstriche (_) zur Trennung, also etwa so:

neue_prozedur

Ist doch einfach, oder?

9.3 Namen:
9.3.1 Sinn des Wählens aussagekräftiger Namen für Prozeduren
Kommentare haben wir bereits kennen gelernt, um uns zu merken, was eine Prozedur im Einzelnen tut. Aber noch viel wichtiger als das sind aussagekräftige Namen. Mit einem Prozedurnamen wie drehe_rechts kann man i.d.R. deutlich mehr anfangen als mit einem wie v0l3 (v0 steht für 0 Schritte vor und l3 für 3x links)! Man kann zwar damit arbeiten, aber niemand anderes würde eine solche Logik nachvollziehen wollen (und evtl. auch können). Noch etwas: in der Kürze liegt die Würze! Ellenlange Namen enthalten zwar mehr Information, werden aber nur ungern noch mal an der Stelle eingetippt, an der sie verwendet werden sollen. Daher ist eine gelungene Abkürzung der richtige Name. drehe_rechts ist deutlich schneller einzutippen als drehe_um_und_dann_nochmal_links, auch wenn man beim letzteren den Kommentar weglassen kann. Beide sagen dasselbe aus und daher ist die kurze Version besser.