Über das Schreiben von Ausdrücken

• Einige der Vorrangregeln in C sind nicht einleuchtend. Falls Sie unsicher sind, benutzen Sie Klammern, um die Reihenfolge und Priorität der Bewertung anzugeben. Denken Sie jedoch daran, daß der Compiler die Bewertungsreihenfolge bestimmter Ausdrücke (solche, die nur die Operatoren &, /, ^, + oder * enthalten), selbst bei Anwesenheit von Klammern, frei wählen kann.
• Typumwandlungen können im allgemeinen benutzt werden, um die Angleichungen an den erforderlichen Typ zu erzwingen. Da Arithmetik mit unterschiedlichen Typen automatische Typangleichung mit sich bringt, die manchmal anders als erwartet ausfällt, benutzen Sie eine Umwandlung, um das Gewünschte zu erhalten.
• Es gibt keine Leistungseinbuße durch die Bewertung von Konstantenausdrücken, da sie zur Compilationszeit bewertet werden. Zum Beispiel wandelt der Compiler den Ausdruck a = 17.3 / 14.7 * PI / vals[i]; (vorausgesetzt, PI ist als 3.14159 definiert worden) in a = 3.697245371 / vals[i]; um.
• Einige C-Operationen können geschickt in vielfältiger Weise eingesetzt werden. Zum Beispiel kann das logische UND zweier Bedingungen manchmal durch das bitweise UND ersetzt werden, was möglicherweise schneller zu bewerten ist. Das ist jedoch nur angebracht, wenn Sie alle Bedingungen bewertet haben wollen.
• Seien Sie vorsichtig bei der Benutzung der additiven Operatoren ++ und --. Im allgemeinen sollten Sie nicht mehr als einen vor- oder nachgestellten Operator in einem einzelnen Ausdruck benutzen. Welches Ergebnis haben beispielsweise die folgenden Ausdrücke?

  a[i++] = a[--i];

  a[--i] = b[++i];

• Es ist leicht, unklare Ausdrücke zu schreiben. Selbst wenn diese Ausdrücke vom Compiler eindeutig interpretiert werden können, werden sie doch die meisten Programmierer verwirren. Wenn Sie sich nicht sicher sind, vereinfachen Sie es.

Programmformat

• Kommentare, die sich über mindestens eine Zeile erstrecken, sind linksbündig am Code ausgerichtet. Sie sollten beschreiben, was in den folgenden Programmzeilen bis zur nächsten Leerzeile geschieht.
  Ist ein Programmblock länger als 20 - 30 Zeilen, sollte ein Kommentar am Blockende auf den Blokanfang verweisen (z. B. /* Ende: while (x > 0) ... */ Funktionsbeschreibungen enthalten alle Parameter, Fehlerfälle und Rückgabewert. Ggf.muss auch angegeben werden, ob ein Parameter Eingabewwert, Ausgabewert oder beides ist. Die Beschreibung erfolgt direkt nach der Definition des Funktionskopfes noch vor den Block der Funktion.
• Formatieren Sie die Anweisungen durch Einrücken so, daß man die Anweisungs- und Blockstruktur erkennen kann. Achten Sie auf Lesbarkeit. Klammern oder Schlüsselworte zur Blockdefinition sollten in einer separaten Zeile stehen. Programmblöcke müssen durch Einrückung erkennbar (2 - 3 Leerschritte, keine Tabulatorzeichen) und linksbündig ausgerichtet sein. Beispiel:

                                            if (wert > 10)
                                              {
                                              /* tu was */
                                              /* tu noch was */
                                              }
                                         

  Code im globalen Kontext (z. B. die Definition einer global sichtbaren Funktion) darf nicht eingerückt sein.
  Eine Sprungmarke (Label) sollte eine einfache negative Einrückung zum vorhergehenden Code aufweisen.
• Trennen Sie Vereinbarungen und Anweisungen durch eine Leerzeile, auch wenn das nicht vom Compiler gefordert wird. Scheuen Sie sich nicht, weitere Leerzeilen einzufügen. Funktionen sollten vom vorhergehenden Code durch 2 - 3 Leerzeilen getrennt werden. Einzelne zusammengehörende Codezeilen können durch eine Leerzeile vom vorhergehenden Code getrennt werden.
  Die maximale Zeilenbreite des Quellcodes sollte maximal 70 - 75 Anschläge umfassen. Längere Zeilen müssen umbrochen werden. Der Umbruch eines Ausdrucks sollte an der Stelle eines Operators erfolgen, der keine höhere Priorität hat als der vorhergehende oder nachfolgende. Die umbrochene Zeile kann weiter eingerückt werden.
  Die Zeilentrennung bei Auflistungen (z. B. Initialisierung eier Array-Variablen oder Parameterliste beim Funktionsaufruf) sollte nach dem Trennungszeichen erfolgen. Der Eintrag in der Folgezeile wird linksbündig nach dem ersten Eintrag ausgerichtet.
• Vermeiden Sie es, zusammengesetzte Anweisungen in eine Zeile zu schreiben. Ausdrucks­anweisungen, die einen Bezug aufeinander haben, können unter Benutzung des Kommaoperaters verknüpft werden. Ausdrucksanweisungen, die keinen Bezug zueinander haben, haben Anspruch auf eigene Zeilen.
• Vermeiden Sie es, den Anweisungsteil einer Schleifen- oder Entscheidungsanweisung in dieselbe Zeile zu schreiben wie den Schleifensteuerungsausdruck. Die zwar kürzere Form ist schlechter lesbar und anfälliger gegen Fehler wie das irrtümliche Einfügen einer leeren Anweisung.
• Vergessen Sie nicht, bedingte Ausdrücke in Klammern einzuschließen. Denken Sie auch daran, daß dem while kein "do" folgt und dem if kein "then"; das Einfügen dieser Schlüsselwörter verursacht Syntaxfehler.
• Präprozessoranweisungen:
  Pfadangaben bei #include-Anweisungen erfolgen relativ zum Projektverzeichnis. Absolute Pfade sind verboten. Projektspezifische Include-Dateinamen stehen zwischen "...". Spitze Klammern sind für Standard-Headerfiles und projektübergreifende Dateien reserviert. Der Name einer Headerdatei darf sich nur in der Dateiendung von der Implementierungsdatei unterscheiden (z. B.: "foo.h" gehört zu "foo.c").
  Namen von Makros dürfen nur Grossbuchstaben und das Unterstreichungszeichen enthalten. Alle Makros zur bedingten Compilierung müssen im Dateikopf und der Projektdokumentation beschrieben werden.
  In einer Header-Datei müssen Deklarationen in folgender Reihenfolge stehen: Makros, Typen, globale Variable, lokale Variable (static), Prototypen lokaler Funktionen, globale Funktionen, lokale Funktionen.
• Schließlich, unterliegen Sie nicht der Versuchung vieler C-Programmierer, herauszufinden, wie man ein Programm in der knappsten möglichen Form schreiben kann. Wenn Sie unbedingt das Bedürfnis haben, tun Sie es, aber werfen Sie das Programm anschließend weg, denn es ist nicht mehr lesbar - oder nehmen Sie am Obfuscated C Contest teil.

Ein paar Regeln zur Schreibweise

• Delimiter und Ausdrücke
  Delimiter von Statements (der Strichpunkt) oder Variablen (das Komma) dürfen nicht unmittelbar einem Leerzeichen folgen, müssen aber von einem Zeilenvorschub, einem Leerzeichen oder weiteren Delimitern gefolgt werden.
• Trennzeichen in zusammengesetzten Datentypen
  Trennzeichen für zusammengesetzte Datentypen (also z.B. der Punkt beim Spezifizieren der Komponente einer struct oder union in C) dürfen weder direkt vor einem Leerzeichen stehen noch direkt von einem Leerzeichen gefolgt werden.
• Leerzeichen und Zuweisungsoperator
  Der Zuweisungsoperator muss zwischen zwei Leerzeichen oder zwischen einem Leerzeichen und einem Zeilenvorschub stehen.
• Leerzeichen und unäre Operatoren
  Unäre Operatoren (z.B. der Adressoperator & oder der Inhaltsoperator *) dürfen von ihrem Operanden nicht durch ein Leerzeichen getrennt werden.
• Unäre Operatoren als Teil von Datendeklarationen
  Ein unärer Operator, der in der Bezeichnung einer Variablen vorkommen kann, darf vom Variablenbezeichner nicht getrennt werden.
• Leerzeichen und biäre Operatoren
  Biären Booleschen Operatoren (z. B. &&, ||) muss ein Leerzeichen direkt vorangehen und eines direkt nachfolgen. Die Leerzeichen um biäre Operatoren darf visuell nicht den Vorrangregeln arithmetischer Ausdrücke wiedersprechen . Ein Leerzeichen muss entweder auf beiden Seiten des Operators stehen oder auf keiner Seite.
• Empfehlung zur Klammersetzung
  Eine öffnende eckige oder runde Klammer sollte einem Leerzeichen, Zeilenvorschub, einer anderen Klammer oder einem Funktions-/Variablennamen folgen und nicht direkt von einem Leerzeichen gefolgt werden. Eine schliessende eckige oder runde Klammer sollte nicht direkt hinter einem Leerzeichen stehen und sollte direkt von einem Trennzeichen, Delimiter oder einer weiteren Klammer gefolgt werden. Vor öffnenden Klammern, welche die Parameter vom Namen einer Funktion trennen, sollte kein Leerzeichen stehen. Zwischen einem Schlüsselwort (if, while, do, etc.) und einer öffnenden Klammer muss ein Leerzeichen stehen.

Über das Schreiben leicht lesbarer Programme

• Zusammenhalt: Eine Funktion sollte nur eine Aufgabe ausführen und alle Anweisungen in der Funktion sollten auf diese Aufgabe bezogen sein. Wenn die Wirkungsweise der Funktion nicht in einem einzigen Satz beschrieben werden kann, versucht die Funktion, zu viel zu tun.
• Allgemeingültigkeit Eine Funktion sollte ihre eine Aufgabe gut erfüllen. Eine Sortierroutine sollte z.B. für alle Eingabemengen gut arbeiten und Fehlerfälle (wie wenn keine zu sortierenden Elemente vorhanden sind) angemessen behandeln.
• Einfachheit: Eine Funktion sollte ihre Aufgabe auf die einfachst mögliche Weise erledigen; versuchen Sie nicht, durch übertriebenes Ausfeilen des Codes noch ein oder zwei Operationen einzusparen. Im allgemeinen wird ein Wechsel des Algorithmus mehr zur Effizienz beitragen als irgendwelche Manipulationen am Code.
• Kürze: Funktionen, die eine einzelne Aufgabe in einfacher Weise erledigen, sind im allgemeinen nicht lang. Es bewährt sich, Funktionen auf ca. 25 bis 200 Zeilen) zu beschränken. Natürlich können auch zu viele kleine Funktionen ein Programm zu sehr zerreißen und damit die Lesbarkeit und die Effizienz des Programms ruinieren. Die meisten Programmierer schreiben jedoch eher zu lange als zu kurze Funktionen.
• Dokumentation: Jede Funktion hat Anspruch auf einen Kommentar, der ihm Aufgabe beschreibt. Die Parameter und lokalen Variablen der Funktion sollten ebenfalls kommentiert werden. Häufig genügt ein einziger Satz zur Beschreibung der Funktion oder Variablen. Schreiben Sie die Kommentare immer gleichzeitig mit dem Code, und warten Sie nicht, bis die Funktion fertig geschrieben ist.

Schreiben von Makros

• Ersetzen Sie einfache Funktionen aus Effizienzgründen durch Makros. Achten Sie jedoch darauf, daß Sie nicht versuchen, zu viel in einem Makro zu tun. Es lohnt sich nicht, eine Funktion in ein Makro umzuschreiben, wenn der Verwaltungsaufwand des Funktionsaufrufs gering im Vergleich zu dem ist, was die Funktion ausführt.
• Ersetzen Sie, um den Code zu vereinfachen, komplizierte oder verwirrende Ausdrücke durch Makros. Durch das Makro erhält der Ausdruck einen Namen, was der Lesbarkeit dient. Dies ist besonders wichtig, wenn der Ausdruck an mehreren Stellen vorkommt.
• Schreiben Sie Makros, die in Ausdrücke und nicht in Anweisungen umgewandelt werden. Dadurch erreichen Sie, daß der Makroaufruf überall dort verwendet werden kann, wo auch ein Funktionsaufruf stehen kann. Wenn das nicht möglich ist, schließen Sie den Text des Makros in geschweifte Klammern ein, Sie dürfen dann allerdings das Makro nicht mit einem Semikolon abschließen.
• Vermeiden Sie Seiteneffekte in Makroaufrufen, unterstellen Sie nie, daß Argumente nur einmal bewertet werden, und stellen Sie keine Vermutungen darüber an, in welcher Reihenfolge Argumente bewertet werden. Diese Regeln gelten auch für Funktionen, da es manchmal nicht möglich ist, zu entscheiden, ob ein Aufruf einem Makro oder einer Funktion gilt.
• Klammern Sie Ausdrücke innerhalb eines Makroersatztextes, um sich gegen unerwartete Ergebnisse bei der Makroumwandlung zu schützen. Makrotexte, die in Ausdrücke umgewandelt werden, sollten ebenfalls geklammert werden.

Zeiger und Arrays

• Benutzen Sie Arrays mit Zeigern auf Zeichenketten anstatt zweidimensionaler Arrays, wenn die Zeichenketten unterschiedlich lang sind Zur Speicherzuweisung für die Zeichenketten sollten Sie malloc benutzen, um einiges von dem sonst bei jeder Zeichenkette vergeudeten Speicherplatz einzusparen. Merken Sie sich jedoch, daß bei der Vereinbarung eines Arrays aus Zeigern nicht automatisch Speicherplatz für das, worauf die Zeiger zeigen, zugewiesen wird.
• Fragen Sie den Rückgabewert von malloc immer ab. Unterlassen Sie das, können Sie sich ernsthafte Schwierigkeiten bereiten, die in den meisten Fällen zu einem Abbruch Ihres Programms durch das Betriebssystem führen, insbesondere, wenn Sie versuchen, mit einem Zeiger auf NULL Speicherplatz zuzuweisen. Es kann sein, daß Sie nichts Sinnvolles mehr tun können, wenn der verbliebene dynamische Speicher nicht mehr aus- reicht; die Entscheidung, das Programm dann abzubrechen, sollte jedoch bei Ihnen liegen. Die allgemeine Regel besagt, daß maschinennahe Routinen wie solche, die malloc aufrufen, dem Aufrufenden mitteilen sollten, daß es Schwierigkeiten gibt. Der aufrufende Teil sollte sich dann um den Fehler kümmern.
• Benutzen Sie typedef, um Vereinbarungen und Umwandlungen lesbar zu gestalten. Selbst wenn Sie in der Lage sind, komplexe Vereinbarungen zu verstehen, wird es unter den Lesern Ihres Programms sicher welche geben, die es nicht können.

Benutzung selbstdefinierter Typen

• Benutzen Sie Aufzählungstypen, wenn eine Variable einen Wert aus einer Menge von Werten annehmen kann. Sie bieten eine bequeme Möglichkeit, Konstanten zu definieren, fördern die Lesbarkeit und ermöglichen zusätzliche Typprüfung durch den Compiler. Beachten Sie jedoch, daß Aufzählungstypen keine Ganzzahlen sind und erst in geeigneter Weise umgewandelt werden müssen, wenn sie als Ganzzahlen benutzt werden sollen.
• Benutzen Sie Strukturen, wenn Sie Daten, die in einem engen Zusammenhang stehen, speichern wollen. Strukturen bieten außerdem eine weitere Möglichkeit, Informationen zu verbergen, da sie im Ganzen verarbeitet werden können, ohne daß man sich um den Inhalt ihrer Felder kümmern muß. Benutzen Sie Varianten, wenn ein Speicherplatz verschiedene Typen aufnehmen soll.
• Beachten Sie den Unterschied zwischen Strukturen und Varianten, der darin besteht, daß jedem Glied einer Struktur Speicherplatz zugewiesen wird, bei Varianten jedoch nur ein Platz entsprechend dem längsten Feld zugewiesen wird. Sie können nur jeweils einen Wert in einem Feld einer Variante speichern.
• Unterstellen Sie nie, daß die Felder einer Struktur fortlaufend gespeichert sind. Strukturen werden oft aufgefüllt, um Ausrichtungsnotwendigkeiten zu erfüllen. Die Annahme, daß nicht aufgefüllt wird, führt zu nicht portierbarem Code.

Dynamische Datenstrukturen

• Dynamische Datenstrukturen ersparen dem Programmierer viel Zeit. Sie haben außerdem die angenehme Eigenschaft, daß sie Speicher für beliebige Wertezusammenstellungen bereitstellen, wobei nur Speicherplatz für die tatsächlich gespeicherten Werte verbraucht wird. Schließlich sind sehr viele Algorithmen am einfachsten zu implementieren, wenn dynamisch zugewiesener Speicher zur Verfügung steht.
• Dynamische Datenstrukturen sind jedoch zur Laufzeit nicht notwendigerweise effizienter. Normalerweise müssen das Betriebssystem und die Laufzeitumgebung von C den frei zur Verfügung stehenden Speicherplatz so verwalten, daß Knoten jeder Größe in beliebiger Reihenfolge angefordert und freigegeben werden können. Bei Arrays fester Größe entlasten wir das System zur Laufzeit, müssen jedoch als Ausgleich dafür den Speicherbedarf im voraus genau angeben.
• Speicherzuweisung für dynamische Datenstrukturen kann versagen; daher müssen wir den Rückgabewert von malloc prüfen. Diese Funktion versagt (gibt NULL zurück), wenn im System kein Speicher mehr vorhanden ist.

Auswahl der geeignetsten Bibliotheksfunktion

• Benutzen Sie nach Möglichkeit immer zeichenweise Ein- und -ausgabe. Die Funktionen getc, putc, getchar und putchar sind effizienter und einfacher zu benutzen als die anderen Bibliotheksfunktionen.
• Benutzen Sie bei Anwendungen, bei denen eine zeilenweise Verarbeitung ihrer Eingabe nahe liegt, die zeilenorientierten Funktionen fgets, fputs, gets und puts. Sie sind nicht so effizient wie die Zeichen-E/A-Funktionen, sind aber effizienter als die formatierten E/A-Funktionen scanf, printf. Passen Sie jedoch bei Zeilen auf, die länger als erwartet sind.
• Sparen Sie sich die formatierten Funktionen für die Fälle auf, in denen sie wirklich benötigt werden: Lesen und Schreiben formatierter Ein- und Ausgabe. Wegen des zusätzlichen Aufwandes beim Analysieren der Formatzeichenkette sind sie erheblich langsamer und erzeugen wesentlich mehr Code als alle anderen E/A-Funktionen.
• Benutzereingaben sind grundsätzlich als fehlerbehaftet und unkorrekt zu betrachten.

Zurück

Inhaltsverzeichnis

Nächste