\chapter{Programmierstil}

\section{Allgemeines}

Ein einheitlicher Programmierstil erh"oht die Lesbarkeit von
Programmen und f"ordert damit die Transparenz und die Wiederverwendbarkeit
von Modulen. Aus diesem Grund werden f"ur libCUI Programme ein paar
Hinweise gegeben, wie der Quelltext strukturiert sein sollte.

Diese Hinweise sind weder vollst"andig noch erheben sie den Anspruch
darauf, der Weisheit letzter Schluss zu sein. Vielmehr ist einiges
davon Geschmacksache und es bleibt dem Programmierer "uberlassen, ob
er sich daran h"alt oder nicht.

In dem Augenblick allerdings, in dem Code zur Bibliothek hinzugef"ugt 
werden soll (die Mithilfe daran ist jederzeit sehr willkommen), sind
diese Hinweise als Richtlinien zu verstehen auf deren Einhaltung 
bestanden wird. Denn, um die Pflege der hinzugef"ugten Komponenten zu
gew"ahrleisten, ist es erforderlich, dass der Code nicht
nur f"ur den urspr"unglichen Autor verst"andlich ist.

Im "ubrigen ist diese Aufz"ahlung keineswegs vollst"andig. Falls jemand 
weiter Hinweise zur Verbesserung der Code-Qualit"at liefern kann, werden
seine Anmerkungen gerne angenommen und ggf. hier hinzugef"ugt.

\section{Formatierung}

\subsection{Einr"uckungen}
Einr"uckungen werden mit dem Tabulatorzeichen und nicht mit Leerzeichen
vorgenommen. Der Grund liegt darin, dass viele Editoren und 
Entwicklungsumgebungen den Programmierer bei der Formatierung des
Quelltextes unterst"utzen (manchmal sogar eine Formatierung erzwingen)
und dabei in der Regel immer Tabulator-Zeichen verwenden. 

Wird dann an anderer Stelle mit Leerzeichen gearbeitet, dann f"allt
das Problem auf den ersten Blick nicht auf. In der Ansicht eines
anderen Editors (mit anderen Tabulatoreinstellungen) sieht der
Quelltext dann aber wie Kraut und R"uben aus, was zu vermeiden ist,
indem konsequent mit Tabulatoren gearbeitet wird.

\subsection{Programmbl"ocke}

Programmbl"ocke werden in geschweifte Klammern eingeschlossen, wobei
die Schreibweise bevorzugt wird, bei der die Klammern "ubereinander
stehen. Also:

\begin{verbatim}
   if (MyFlag == TRUE)
   {
      /* do something */
   }
   else
   {
      /* do something else */
   }
\end{verbatim}

an Stelle von:

\begin{verbatim}
   if (MyFlag == TRUE) {
      /* do something */
   }
   else {
      /* do something else */
   }
\end{verbatim}


\subsection{Ausdr"ucke}

In Ausdr"ucken werden Operatoren, Zahlen und Variablen durch Leerzeichen
voneinander getrennt. Das macht den Quelltext auch in Editoren lesbar,
die nicht "uber Syntax- Hervorhebung verf"ugen. Also:

\begin{verbatim}
   result = 3 * (x / 4);
\end{verbatim}

an Stelle von:

\begin{verbatim}
   result = 3*(x/4);
\end{verbatim}


\subsection{Funktionsnamen}

Funktionsnamen werden innerhalb der libCUI in Pascal-Case angegeben.
Dabei werden semantische Einheiten des Namens durch Gro"sbuchstaben
hervorgerufen. Sie enthalten keine Unterstriche. 

Beispiele: ''WindowClose'' oder ''EditNew''.

Zudem wird dem Namen der Name des Moduls in dem die Funktion 
implementiert wurde vorangestellt. Die Funktion ''EditNew'' findet
sich beispielsweise im Programmmodul (Source-Datei) ''edit.c'' wider. 
Bei sehr langen Modulnamen kann das nat"urlich entsprechend 
gek"urzt werden. 

Funktionen, die nicht an andere Module exportiert werden (lokale
Funktionen des Moduls) werden mit dem Schl"usselwort ''static''
versehen. Das vermeidet Namenskonflikte, erh"oht die Kapselung
der Funktion in einem Modul. Zudem kann schon der Compiler auf
nicht verwendeten Code hinweisen.

\subsection{Variablen}

Globale Variablen werden in Gro"sbuchstaben geschrieben, wobei
ebenfalls die Pascal-Case Notation zum Einsatz kommt. Dabei 
werden semantische Einheiten des Namens durch Gro"sbuchstaben
hervorgerufen. Auch sie enthalten keine Unterstriche. 

Lokale Variablen und Funktionsparameter dagegen werden in 
Kleinbuchstaben geschrieben. Optional kann hier der Unterstrich
zur Hervorhebung der Lesbarkeit verwendet werden.

Globale Variablen, die nur innerhalb des Moduls sichtbar sind 
(Regelfall), erhalten zudem das Schl"usselwort ''static''.

Beispiel:

\begin{verbatim}

static int MyFlag;

void SwitchItOn(int flag_state)
{
   MyFlag = flag_state;
}

\end{verbatim}


\section{Struktur eines Moduls}

Jede Fensterklasse sollte in einer eigenen Source-Datei
implementiert werden. Damit erh"alt man ein Modul pro
Fensterklasse.

Innerhalb des Moduls ergibt sich dann der folgende Aufbau:

1. Einbindung von Header-Dateien und Definitionen
2. Typdefinition der Instanzdaten
3. Prototypen lokaler Funktionen
4. Globale Variablen
5. Hook-Funktionen
6. Funktion zum Anlegen der Fensterklasse
7. Zugriffsfunktionen auf die Fensterinstanz
8. Lokale Hilfsfunktionen

Bei Dialogen und anderen Fenstern, die Daten mit anderen
Modulen austauschen m"ussen, kann (und muss) die Typdefinietion der 
Instanzdaten in der Header-Datei des Moduls erfolgen.

