Improved progrsmming style chapter.

header.tex

@@ -171,6 +171,7 @@
 \newcommand{\enterm}[1]{``#1''}
 \newcommand{\determ}[1]{\textit{#1}}
 \newcommand{\codeterm}[1]{\textit{#1}}
+\newcommand{\keycode}[1]{\texttt{#1}}
 \newcommand{\file}[1]{\texttt{#1}}
 
 %%%%% code/matlab commands: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

programmingstyle/code/calculate_sines.m

@@ -12,7 +12,7 @@ function sines = calculate_sines(x, amplitudes, frequencies)
   sines = zeros(length(x), length(amplitudes), length(frequencies));
 
   for i = 1:length(amplitudes)
-    sines(:, i, :) = sines_with_frequencies(x, amplitudes(i), frequencies); 
+    sines(:,i,:) = sines_with_frequencies(x, amplitudes(i), frequencies); 
   end
 end
 
@@ -27,4 +27,4 @@ end
 
 function sine = sinewave(x, amplitude, frequency)
     sine = sin(2 .* pi .* x *frequency) .* amplitude; 
-end
+end

programmingstyle/lecture/programmingstyle.tex

@@ -8,8 +8,8 @@ machen.
 Programme sollten so geschrieben und strukturiert sein, dass es sowohl
 einem Au{\ss}enstehenden als auch einem selbst, nach ein paar Monaten,
 leicht f\"allt den Programmablauf nachzuvollziehen und zu
-verstehen. Saubere Programmierung zahlt sich auch f\"ur den Sch\"opfer
+verstehen. Saubere Programmierung zahlt sich aber in erster Linie
-eines Programmes aus.
+f\"ur den Verfasser eines Programmes aus.
 
 Guter Programmierstil greift auf unterschiedlichen Ebenen an:
 \begin{enumerate}
@@ -22,49 +22,48 @@ Guter Programmierstil greift auf unterschiedlichen Ebenen an:
 \item Auslagerung von Funktionalit\"at in eigene Funktionen.
 \end{enumerate}
 
-\section{Struktur von Programmen, Organisation von m-Files im Dateisystem}
+\section{Organisation von m-Files im Dateisystem}
 
 In der Einf\"uhrung zu Funktionen und Skripten wurde schon einmal ein
-typisches Programmlayout vorgestellt (Abbildung
+typisches Programmlayout vorgestellt (\figref{programlayoutfig}). Hier
-\ref{programlayoutfig}). Hier wurde vorgeschlagen ein Skript als
+wurde vorgeschlagen ein Skript als Kontrollskript zu verwenden. Dieses
-Kontrollskript zu verwenden. Dieses kontrolliert den weiteren
+kontrolliert den weiteren Programmablauf, ruft Funktionen auf,
-Programmablauf, ruft Funktionen auf, \"ubergibt Argumente und nimmt
+\"ubergibt Argumente und nimmt R\"uckgabewerte entgegen. Eine solche
-R\"uckgabewerte entgegen. Eine solche Struktur macht es einfach den
+Struktur macht es einfach den Ablauf zu verstehen. Es bleibt aber die
-Ablauf zu verstehen. Es bleibt aber die Frage, wie man das
+Frage, wie man das Kontrollskript unter den anderen \codeterm{m-files}
-Kontrollskript unter den anderen \codeterm{m-files} als solches
+als solches erkennt. Um dieses zu erleichtern gilt es zwei Dinge zu
-erkennt. Um dieses zu erleichtern gilt es zwei Dinge zu beachten:
+beachten: (i) Wie werden Programme im Dateisystem organisiert? (ii) Wie
-1. Wie werden Programme im Dateisystem organisiert? 2. Wie werden
+werden Programme benannt?
-Programme benannt?
 
 Es hilft ungemein, wenn zusammengeh\"orige Skripte und Funktionen im
 gleichen Ordner auf der Festplatte zu finden sind. Es bietet sich also
-an f\"ur jede Analyse einen eigenen Ordner anzulegen und in diesem die
+an, f\"ur jede Analyse einen eigenen Ordner anzulegen und in diesem die
 zugeh\"origen \codeterm{m-files} abzulegen. Auf eine tiefere
 Schachtelung in weitere Unterordner kann in der Regel verzichtet
-werden. \matlab{} erzeugt einen ``MATLAB'' Ordner im eingenen
+werden. \matlab{} erzeugt einen ``MATLAB'' Ordner im eigenen
-``Documents'' (Linux) oder ``Eigene Dokumente'' (Windows) Ordner. Es
+\file{Documents} (Linux) oder \file{Eigene Dokumente} (Windows) Ordner. Es
-bietet sich an diesen als Wurzelverzeichnis f\"ur eigene Arbeiten zu
+bietet sich an, diesen Ordner als Wurzelverzeichnis f\"ur eigene Arbeiten zu
 verwenden. Nat\"urlich kann auch jeder andere Ort gew\"ahlen
-werden. In dem Beispiel in Abbildung \ref{fileorganizationfig} wird
+werden. In dem Beispiel in \figref{fileorganizationfig} wird
 innerhalb dieses Ordners f\"ur jedes Projekt ein eigener Unterordner
-erstellt in welchem widerum f\"ur jedes Problem, jede Analyse ein
+erstellt, in welchem widerum f\"ur jedes Problem, jede Analyse ein
 weitere Unterodner erstellt wird. In diesen liegen sowohl die
-ben\"otigten m-files also auch die Resultate der Analyse (Abbildungen,
+ben\"otigten \codeterm{m-files} also auch die Resultate der Analyse (Abbildungen,
-Dateien). Zu bemerken sind noch zwei weitere Dinge. Im Projektordner
+Daten-Dateien). Zu bemerken sind noch zwei weitere Dinge. Im Projektordner
 existiert ein Skript (analysis.m), das dazu gedacht ist, alle Analysen
 aufzurufen. Des Weiteren gitb es parallel zu den Projektordnern einen
-``functions'' Ordner in dem Funktionen liegen, die in mehr als einem
+\file{functions}-Ordner in dem Funktionen liegen, die in mehr als einem
 Projekt oder einer Analyse gebraucht werden.
 
-Wenn man sich dieses Layout anschaut f\"allt auf, dass es sehr
+Beim Betrachten dieses Layouts f\"allt auf, dass es sehr
 wahrscheinlich ist, dass bestimmte Namen f\"ur Funktionen und Skripte
 mehrfach verwendet werden. Es ist nicht verwunderlich, wenn eine
-``load\_data.m'' Funktion in jeder Analyse vorkommt. In der Regel wird
+\file{load\_data.m} Funktion in jeder Analyse vorkommt. In der Regel
-dies nicht zu Konflikten f\"uhren, da \matlab{} zuforderst im
+wird dies nicht zu Konflikten f\"uhren, da \matlab{} zuerst im
-aktuellen Ordner nach passenden Dateien sucht (mehr Information in Box
+aktuellen Ordner nach passenden Dateien sucht (mehr Information zum
-\ref{matlabpathbox}).
+\matlab-Suchpfad in Box~\ref{matlabpathbox}).
 
-\begin{figure}
+\begin{figure}[tp]
   \includegraphics[width=0.75\textwidth]{program_organization}
   \titlecaption{\label{fileorganizationfig} M\"ogliche Oganisation von
     Programmcode im Dateisystem.}{ F\"ur jedes Projekt werden
@@ -74,7 +73,7 @@ aktuellen Ordner nach passenden Dateien sucht (mehr Information in Box
 \end{figure}
 
 
-\begin{ibox}[t]{\label{matlabpathbox}Der \matlab{} Suchpfad}
+\begin{ibox}[tp]{\label{matlabpathbox}Der \matlab{} Suchpfad}
   Der Suchpfad definiert, wo \matlab{} nach Skripten und Funktionen
   sucht. Wird eine Funktion aufgerufen wird zun\"achst im aktuellen
   Arbeitsverzeichnis einem Treffer gesucht. Schl\"agt diese Suche
@@ -109,14 +108,24 @@ aktuellen Ordner nach passenden Dateien sucht (mehr Information in Box
 
 \matlab{} sucht Funktionen und Skripte ausschlie{\ss}lich anhand der
 Namen. Dabei spielt die Gro{\ss}- und Kleinschreibung eine Rolle. Das
-hei{\ss}t, dass die Namen ``test\_funktion.m'' und ``Test\_funktion.m''
+hei{\ss}t, dass die beiden Dateien \file{test\_funktion.m} und
-zwei unterschiedliche Funktionen benennen k\"onnen. Diese Art
+\file{Test\_funktion.m} zwei unterschiedliche Funktionen benennen
-Variation des Namens ist nat\"urlich nicht sinnvoll. Sie tr\"agt keine
+k\"onnen. Diese Art der Variation des Namens ist nat\"urlich nicht
-Information \"uber den Unterschied der beiden Funktionen. Auch sagt
+sinnvoll. Sie tr\"agt keine Information \"uber den Unterschied der
-der Name nahezu nichts \"uber den Zweck der Funktion aus. Die
+beiden Funktionen. Auch sagt der Name nahezu nichts \"uber den Zweck
-Namensgebung f\"allt mitunter nicht leicht, es lohnt sich aber
+der Funktion aus. 
-ausdruckstarke Namen zu finden. Ausdrucksstark bedeutet, dass sich aus
+
-dem Namen ein R\"uckschluss auf den Zweck ziehen lassen sollte.
+Die Namensgebung f\"allt mitunter nicht leicht --- manchmal ist es
+sogar der schwierigste Aspekt des Programmierens!  Ausdrucksstarke
+Namen zu finden lohnt sich aber. Ausdrucksstark bedeutet, dass sich
+aus dem Namen ein R\"uckschluss auf den Zweck ziehen lassen sollte.
+
+\begin{important}
+  Die Namen von Funktionen und Skripte sollten m\"oglichst viel \"uber
+  die Funktionsweise oder den Zweck aussagen (\file{firingrates.m}
+  statt \file{uebung.m}). Gute Namen f\"ur Funktionen und Skripte sind
+  die beste Dokumentation.
+\end{important}
 
 \matlab{} macht keine weiteren Vorgaben, was die Namen
 angeht. Allerdings folgt die Benennung der vordefinierten Funktionen
@@ -131,12 +140,12 @@ gewissen Mustern:
   Wertes in einen Text) benannt.
 \end{itemize}
 
-Andere \"ubliche Muster sind der \emph{camelCase} bei dem die
+Andere \"ubliche Muster sind der \emph{camelCase}, bei dem die
 Anf\"ange zusammengesetzter Worte jeweils gro{\ss} geschrieben werden
 oder auch die Verwendung von Unterstrichen zur Trennung von
-Namenskomponenten. Eine Funktion, die die Anzahl Aktionspotentiale
+Namenskomponenten. Eine Funktion, die die Anzahl von
-berechnet k\"onnte etwa \codeterm{spikeCount.m} oder auch
+Aktionspotentialen bestimmt k\"onnte etwa \file{spikeCount.m} oder
-\codeterm{spike\_count.m} benannt werden. Leerzeichen, Sonderzeichen
+\file{spike\_count.m} benannt werden. Leerzeichen, Sonderzeichen
 oder Anf\"ange mit Zahlen sind in Namen nicht erlaubt.
 
 
@@ -146,15 +155,26 @@ F\"ur die Bennennung von Variablen und Konstanten gelten die gleichen
 Regeln wie f\"ur die Namen von Funktionen und Skripten. Die Maxime von
 gutem Programmierstil ist: \emph{``Programmcode muss lesbar
   sein.''}. Dabei helfen gute Namen ungemein. Auch wenn es schwer
-f\"allt passende Namen zu finden, die nicht zu lang werden sollte man
+f\"allt passende und nicht zu lange Namen zu finden, sollte einer gute
-sich auch da M\"uhe geben.
+Namensgebung ernst genommen werden.
 
-Bei den Funktionen und Skripten fragt man danach, welchen Zweck sie
+W\"ahrend die Namen von Funktionen und Skripten ihren Zweck
-erf\"ullen, bei Variablen fragt man nach dem Inhalt. Eine Varaible die
+beschreiben, sollten die Namen von Variablen ihren Inhalt
-die mittlere Anzahl Aktionspotentiale speichert k\"onnte also
+beschreiben. Eine Variable, die die mittlere Anzahl von
-\codeterm{average\_spike\_count} hei{\ss}en. Wenn die Variable nicht nur
+Aktionspotentialen speichert, k\"onnte also
-einen sondern mehrere Werte aufnimmt, dann ist der Plural angebracht
+\codeterm{average\_spike\_count} hei{\ss}en. Wenn die Variable nicht
-(\codeterm{average\_spike\_counts}).
+nur einen sondern mehrere Werte aufnimmt, dann ist der Plural
+angebracht (\codeterm{average\_spike\_counts}).
+
+Die Laufvariablen von \code{for}-Schleifen werden oft nur \code{i},
+\code{j} oder \code{k} benannt und sollten aber die einzige Ausnahme
+bzgl. ausdrucksstarker Namensgebung bleiben.
+
+\begin{important}
+  Die Namen von Variablen sollten m\"oglichst viel \"uber ihren Inhalt
+  aussagen (\code{spike\_count} statt \code{x}). Gute Namen
+  f\"ur Variablen sind die beste Dokumentation.
+\end{important}
 
 
 \section{Codestil}
@@ -163,19 +183,21 @@ Die Lesbarkeit von Programmen wird sehr durch den Codestil
 beeinflusst. Ein Programm, in dem z.B. Schleifenk\"orper nicht (oder
 zuf\"allig) einger\"uckt sind ist deutlich schwerer zu lesen und zu
 verstehen, als eines, in dem eine konsistente Einr\"uckung vorgenommen
-wurde.
+wurde. Mit der Tastenkombination \keycode{Ctrl-I} % XXX Oder wie war das? XXX
+kann ein markierter
+Bereich im \matlab{} Editor automatisch richtig einger\"uckt werden.
 
-Gerne werden Leerzeilen eingef\"ugt um Abschnitte im Programm zu
+Sparsam und konsistent eingef\"ugte einzelne Leerzeilen sind
-trennen. Das ist v\"ollig ok, wenn es konsistent und sparsam benutzt
+hervorragend geeignet, um logische Abschnitte eines Programm zu
-wird. Hier sollte eine Leerzeile ausreichen. Zu gro{\ss}e Abst\"ande
+trennen. Zu viele Leerzeilen haben den Nachteil, dass das Programm
-f\"uhren dazu, dass das Programm nicht mehr auf eine Seite passt und man
+nicht mehr auf eine Seite passt und dadurch leichter der \"Uberblick
-leicht den \"Uberblick verliert.
+verlorgen geht.
 
 Die beiden folgenden Listings \ref{chaoticcode} und \ref{cleancode}
 zeigen die Implementation des random-walk einmal eher chaotisch und
-einmal aufger\"aumt.
+einmal aufger\"aumt und \"ubersichtlich.
  
-\begin{lstlisting}[label=chaoticcode, caption={Random-walk Implementation unaufgr\"aumt.}]
+\begin{lstlisting}[label=chaoticcode, caption={Un\"ubersichtliche Implementation des Random-walk.}]
 num_runs = 10;
 max_steps = 1000;
 
@@ -198,7 +220,7 @@ end
 end
 \end{lstlisting}
 
-\begin{lstlisting}[label=cleancode, caption={Random-walk Implementation etwas ordentlicher.}]
+\begin{lstlisting}[label=cleancode, caption={\"Ubersichtliche Implementation des Random-walk.}]
 num_runs = 10;
 max_steps = 1000;
 positions = zeros(max_steps, num_runs);
@@ -217,64 +239,89 @@ end
 
 \section{Verwendung von Kommentaren}
 
-Kommentare k\"onnen ebenfalls sehr zum Verst\"andnis beitragen. Bei
+Kommentarzeilen werden in \matlab{} mit dem Prozentzeichen \cide{\%}
-allen vordefinierten \matlab{} Funktionen findet sich am Anfang eine
+gekennzeichnet.  Gezielt und sparsam eingesetzte Kommentare sind f\"ur
-Kommentarblock, der den Zweck der Funktion, die verschiedenen
+das Verst\"andnis eines Programms sehr n\"utzlich.  Am wichtigsten
-M\"oglichkeiten des Funktionsaufrufs und die Argumente und
+sind kurze Kommentare, die den Zweck und das Ziel eines Abschnitts im
-R\"uckgabewerte beschreibt. Auch in eingenen Funktionen, vor allem
+Programm erl\"autern (z.B. \code{\% compute mean firing rate over all
-wenn auch andere Personen sie benutzen sollen, sind diese Kommentare
+  trials}).
-hilfreich. H\"aufig werden kurze Kommentare eingesetzt um Abschnitte
+
-im Programm zu trennen. Hierbei sollte man auch sparsam sein. Jede
+Zu viele Kommentare k\"onnen in der Entwicklungsphase eines Programms
-Zeile zu erkl\"aren kann in der Entwicklungsphase eines Programms sehr
+sehr hilfreich sein, bl\"ahen aber den Code auf. Durch die Verwendung
-hilfreich sein, bl\"aht aber den Code auf und bei der Verwendung guter
+guter Variablen- und Funktionsnamen sollten die meisten Zeilen sowieso
-Variablennamen sind viel Zeilen weitestgehend selbsterkl\"arend.
+weitestgehend selbsterkl\"arend sein.
+
+Die beste Dokumentation ist der Code selbst. Gut geschriebener Code
+mit ausdrucksstarken Variablen- und Funktionsnamen ben\"otigt keine
+Kommentare, um den Zweck einzelner Zeilen zu erkl\"aren. z.B. ist\\
+\code{ x = x + 2;   \% add two to x}\\
+ein v\"ollig unn\"otiger Kommentar.
 
 \begin{important}
   \begin{itemize}
-  \item Kommentare sind gut und wichtig aber: Sie m\"ussen richtig
+  \item Kommentare sollen die Absicht eines Programmabschnitts beschreiben.
+  \item Kommentare sind gut und wichtig --- sie m\"ussen aber richtig
     sein!
-  \item Ein Kommentar, der l\"ugt, ist schlimmer als gar kein Kommentar!
+  \item Ein falscher Kommentar ist schlimmer als gar kein Kommentar!
-  \item Kommentare m\"ussen gepflegt werden, sonst sind sie mehr als
+  \item Kommentare m\"ussen gepflegt werden, sonst sind sie wertlos!
-    wertlos!
   \end{itemize}
 \end{important}
-  
+
+\section{Dokumentation von Funktionen}
+
+Bei allen vordefinierten \matlab{} Funktionen findet sich am Anfang
+eine Kommentarblock, der den Zweck der Funktion, die verschiedenen
+M\"oglichkeiten des Funktionsaufrufs und die Argumente und
+R\"uckgabewerte beschreibt. Auch in eingenen Funktionen sind diese
+Kommentare sehr hilfreich. Siehe Listing~\ref{localfunctions} f\"ur
+ein Beispiel einer gut Dokumentierten Funktion.
+
+\begin{important}
+  Funktionen m\"ussen unbedingt kommentiert werde!
+  \begin{itemize}
+  \item In wenigen Zeilen kurz den Zweck der Funktion beschreiben.
+  \item F\"ur jedes Funktionsargument die Bedeutung, der erwartete
+    Datentyp (Zahl, Vektor, Matrix, etc.), und eventuell die Einheit,
+    in der die Zahlen erwartet werden (z.B. Sekunden).
+  \item Ebenso m\"ussen die R\"uckgabewerte beschrieben werden.
+  \end{itemize}
+\end{important}
+
 
 \section{Auslagerung von Aufgaben in Funktionen}
 
-Kommentare oder Leerzeilen werden benutzt um Abschnitte des Codes
+Kommentare oder Leerzeilen werden benutzt, um logische Abschnitte des
-abzutrennen und nazudeuten, dass ab da etwas inhaltlich anderes
+Codes abzutrennen und kurz zu erkl\"aren. Wenn eine
-gemacht wird. Wenn man im Zuge ist, eine solche inhaltliche Trennung
+solche inhaltliche Trennung einzuf\"ugt wird, sollte man sich immer fragen,
-einzuf\"ugen muss man sich immer fragen, ob dieser Teil des Programms
+ob dieser Teil des Programms nicht in eine eigene Funktion ausgelagert
-nicht in eine eigene Funktion ausgelagert werden sollte. Fast immer
+werden sollte. Fast immer kann dies bejaht werden.
-kann man das bejahen.
 
-Abschnitte nicht auszulagern f\"uhrt zu sehr langen m-Files, die
+Abschnitte nicht auszulagern f\"uhrt zu sehr langen
-leicht un\"ubersichtlich sind. Man nennt sie
+\codeterm{m-Files}, die leicht un\"ubersichtlich werden. Diese Art von
-\codeterm{Spaghetticode}. Es ist h\"ochste Zeit \"uber Auslagerung in
+Code wird \codeterm{Spaghetticode} genannt. Es ist h\"ochste Zeit
-Funktionen nachzudenken.
+\"uber Auslagerung in Funktionen nachzudenken.
 
 \begin{important}
-  Wann sollte man Programmteile in eigene Funktionen auslagern?
+  Wann sollten Programmteile in eigene Funktionen ausgelagert werden?
   \begin{itemize}
-  \item Wenn man innerhalb einer Funktion, eines Skripts mehr als zwei
+  \item Wenn innerhalb einer Funktion oder eines Skripts mehr als zwei
-    Einr\"uckungsebenen hat.
+    Einr\"uckungsebenen gebraucht werden.
-  \item Wenn man wiederholte Strukturen im Code hat.
+  \item Wenn sich Strukturen im Code mehr als einmal wiederholten.
-  \item Wenn man versucht ist, diese mit Copy and Paste zu erzeugen.
+  \item Wenn man versucht ist, wiederholte Strukturen  mit Copy and Paste zu erzeugen.
   \end{itemize}
 \end{important}
 
 \subsection{Lokale Funktionen und geschachtelte Funktionen}
 
-Eine M\"oglichkeit Spaghetticode zu vermeiden ist das Auslagern von
+Das Auslagern von Funktionalit\"at in eigene Funktionen f\"uhrt
-Funktionalit\"at in eigene Funktionen. Dies f\"uhrt dazu, dass man
+dazu, dass eine F\"ulle von Dateien erzeugt wird, die die
-eine F\"ulle von Dateien erzeugt, die die \"Ubersichtlichkeit nicht
+\"Ubersichtlichkeit nicht unbedingt erh\"oht. Wenn die auszulagernde
-unbedingt erh\"ohen. Wenn die auszulagernde Funktionalit\"at an vielen
+Funktionalit\"at an vielen Stellen ben\"otigt wird ist es
-Stellen ben\"otigt werden k\"onnte ist es dennoch sinnvol dies zu
+dennoch sinnvol dies zu tun. Wenn nicht, dann bietet \matlab{} die
-tun. Wenn nicht, dann bietet \matlab{} die M\"oglichkeit sogenannte
+M\"oglichkeit sogenannte \codeterm{lokale Funktionen} oder auch
-\codeterm{lokale Funktionen} oder auch \codeterm{geschachtelte
+\codeterm{geschachtelte Funktionen} (\enterm{nested functions}) zu
-  Funktionen} (\enterm{nested functions}) zu erstellen (Listing
+erstellen. Listing \ref{localfunctions} zeigt ein Beispiel f\"ur eine
-\ref{localfunctions} zeigt ein Beispiel f\"ur eine lokale Funktion).
+lokale Funktion.
 
 \lstinputlisting[label=localfunctions, caption={\codeterm{Lokale Funktionen} erh\"ohen die Lesbarkeit sind aber nur innerhalb der definierenden Datei verf\"ugbar.}]{calculate_sines.m}
 
@@ -288,6 +335,7 @@ ist das anders. Diese werden innerhalb eines Funktionsk\"orpers
 ``Mutterfunktion'' zugreifen und diese auch ver\"andern. Folglich
 sollten sie nur mit Bedacht eingesetzt werden.
 
+
 \section{Besonderheiten bei Skripten}
 
 Ein \"ahnliches Problem wurde schon bei der Einf\"uhrung der Skripte
@@ -302,7 +350,7 @@ aussieht.
 \begin{important}
   Es empfiehlt sich zu Beginn eines Skriptes alle Variablen im
   \codeterm{Workspace} zu l\"oschen (\code{clear}). Meist ist auch
-  ein \code{close all} angebracht.
+  ein \code{close all}, um alle Figures zu schlie{\ss}en, angebracht.
 
   Am Ende eines Skriptes sollte der \codeterm{Workspace} mithilfe von
   \code{clear} wieder von all den Variablen ges\"aubert werden, die
@@ -319,9 +367,9 @@ machen Programmiersprachen gibt es Traditionen und \"Ubereink\"unfte,
 diese sollten dann beachtet werden. 
 
 Wiederholte Programmabschnitte sollten in Funktionen ausgelagert
-werden. Wenn diese nich von globalem Interesse sind, kann man auch mit
+werden. Wenn diese nich von globalem Interesse sind, kann mit
 \codeterm{lokalen} oder \codeterm{geschachtelten Funktionen} die
-Lesbarkeit erh\"ohen. 
+\"Ubersichtlichkeit erh\"oht werden. 
 
 \noindent Es lohnt sich auf den eigenen Programmierstil zu achten!\footnote{Literatur zum Programmierstil: z.B. Robert C. Martin: \textit{Clean
   Code: A Handbook of Agile Software Craftmanship}, Prentice Hall}