Praktisches & Grundsätzliches zur Informatik

Domain specific Language, Specification Language, ERD Notation, OOD Notation, UML

Code als Kommentar im Text

Wo sich Code mit Kommentar zu mischen hat, liegt Text vor, der sich an zwei grundverschiedene Leser richtet:

Da das Programm informalen Text nicht verstehen kann, muss er als solcher gekennzeichnet sein (was üblicherweise dadurch geschieht, dass man ihn in Klammern /* und */ schreibt oder als einen mit // beginnenden Zeilenrest).

Spätestens wo man Designsprachen definiert, empfindet man das als unpraktisch (da ja in Designpapieren weit mehr informaler Text auftritt als Code).

Andererseits sollte Design — wo immer das Sinn macht — so notiert sein, dass sich daraus automatisch Code ableiten lässt. Gutes Beispiel solch semiformalen Designs sind Kapitel, die Datenmodelle definieren, siehe etwa dieses Beispiel).

Solch semi-formales Design ist letzlich ein Aufsatz, in den Code eingestreut ist, den Mensch und Programm daran erkennen, dass seine jeweils erste Zeile mit einem möglichst einfachen Fluchtsymbol beginnt, das informaler Text ganz sicher nicht am Anfang einer Zeile enthält (im Beispiel ist das der Bindestrich, wenn er in der ersten Spalte der Zeile auftritt).

Ich habe mir angewöhnt, grundsätzlich jede formale Sprache, für die ich selbst einen Interpreter zu schreiben habe, so zu definieren (sog. Specification Languages oder — wie man heute auch sagt — domänenspezifische Sprachen).

Gute Beispiele solcher Sprachen sind

Jeder Interpreter solch einfacher formaler Notation lässt sich sehr leicht durch Codegeneratoren ergänzen (dann jedenfalls, wenn er eine komplette ERD-artige Darstellung solcher Strukturen im Hauptspeicher erzeugt — was er auf jeden Fall tun sollte).
Wissenswertes zu "UML, OOD Notation, ERD Notation, Specification Language, Domain specific Language" zusammengestellt durch Gebhard Greiter.
tags: Notation1gegreit Language1gegreit OOD1gegreit