Programmieren C / C++ Tipps

Tipps & Lieblingsfehler

• Ist jedem der Unterschied zwischen ++i und i++ klar?
• Ist jedem der Unterschied zwischen = und == klar?
  Achtung: Der Compiler erkennt das nicht als Fehler, weil in den ( ) von if usw.
  beides erlaubt ist (mit sehr unterschiedlicher Wirkung!).
• Ist jedem der Unterschied zwischen 'x' und "x" klar?
• Der Index in einem Array mit n Elementen geht bis n - 1.
  Die Schleife muss daher for (i = 0; i < n; ++i) lauten, nicht <=!
• Pointer:
  • Bei jedem Vergleich, bei jeder Zuweisung, ...:
    Es muss entweder auf beiden Seiten ein Pointer oder auf beiden Seiten ein Wert (kein Pointer) stehen, nicht gemischt!
  • Merke: & liefert den Pointer auf eine Variable,
    * liefert den Wert der Variablen, auf die der Pointer zeigt.
• Bei Strukturen und Objekten:
  . und -> zum Zugriff auf Member nicht verwechseln!
  ("habe ich die Struktur / das Objekt selbst oder einen Pointer darauf?")
• Man kann Struktur-Member nicht in der Strukturtyp-Deklaration initialisieren,
  sondern erst bei der Deklaration einzelner Struktur-Variablen!
• Heimtückischer Fehler:

  if (...);
  {
     ...
  }
  

  (analog für for oder while statt if)
  Der ; ist zuviel!!! Das if / for / while endet beim ; (d.h. hat einen leeren Rumpf), das { ... } dahinter wird daher in jedem Fall genau einmal ausgeführt!
  Nachdem das korrekter C-Code ist, liefert der Compiler für solche Konstrukte keine Meldung!
• Jede Schleife in C/C++ (for, while, do {...} while) ist eine "solange"-Schleife:
  • Für alle Werte, für die die Schleife ausgeführt werden soll, muss die Bedingung wahr sein!
  • Für den ersten Wert, bei dem die Schleife enden soll, muss die Bedingung falsch sein!
• Ein ; am Ende eines Funktionskopfes (nach )) ist falsch, wenn danach die { mit dem Code der Funktion folgt. Wenn es sich hingegen nur um einen Prototypen (Funktionsdeklaration ohne Code) handelt, gehört sehr wohl am Ende ein ;.
• Nach einer } steht normalerweise kein ;,
  aber es gibt 2 Ausnahmen:
  • struct-Typ und class-Deklarationen.
  • { } für Initialwerte.
• Vor einer } steht normalerweise schon ein ;,
  außer bei mehreren aufeinanderfolgenden } und bei Initialwerten.
• Ich empfehle folgenden Stil bei Schleifen:
  • Ist die Schleife ganz leer (kommt bei for öfters vor):
    Bitte {} statt ; ({} sieht man viel besser als ;)!
  • Enthält das if oder die Schleife genau einen Befehl:
    • Wenn der Befehl ganz kurz ist: Ohne { } in dieselbe Zeile.
    • Sonst: In die nächste Zeile, immer mit { }!
      (auch wenn die { } bei einem Befehl nicht nötig sind,
      aber man vergisst sie sicher, wenn man später einen zweiten Befehl dazuschreibt)
• Bitte unterscheiden:
  • Deklarationen von Funktions-Parametern im Funktionskopf:
    Jede Variable einzeln, , dahinter.
  • Deklaration von normalen lokalen oder globalen Variablen:
    Mehrere Variablen mit einem gemeinsamen Typ erlaubt, , dazwischen, ; am Ende.
• Achtung: Deklariert man mehrere Pointer-Variablen nacheinander, braucht jede einen *.
  Man schreibt den * daher sinnvollerweise zum Variablennamen, nicht zum Typ:
  Falsch: list_item* beg, end;
  Richtig: list_item *beg, *end;
  Analog bei mehreren Files: FILE *infile, *outfile;
• Ein #define hat keinen ; am Ende, und kein = zwischen Name und Wert!
• C99 und C++ erlauben Deklarationen im Initialisierungsteil von for-Schleifen.
  Achtung: Solche Variablen gelten nur bis zum } der for-Schleife
  und sind nach der Schleife unbekannt!
• Es gehört zum guten Stil, bei Vergleichen und Zuweisungen mit char-Variablen auch char-Konstanten zu verwenden: Also nicht c = 0;, sondern c = '\0'; (ebenso für ==).
• Seit C99 kennt C auch einen boolschen Typ: Der Header stdbool.h definiert einen Typ bool sowie Konstanten true und false.
  C++ kennt bool immer (ohne Header).
• Nicht vergessen: Wenn bei / (Division) beide Seiten int sind,
  wird ganzzahlig gerechnet und abgeschnitten!
• Achtung: Man lasse von int-Division und Restbildung mit negativen Zahlen die Finger!
  • Im C89-Standard war ausdrücklich undefiniert, ob Richtung 0 oder Richtung minus unendlich abgeschnitten wird, beides kam in der Praxis vor!
  • Im C99 und C++-Standard ist es festgelegt, aber gefühlsmäßig verkehrt (anders als in der Mathematik und in Pascal): Die Division schneidet Richtung 0 ab (d.h. auf das betragsmäßig kleinere Ergebnis), der Rest kann daher eine negative Zahl sein! Das entspricht nicht dem "modulo" in der Mathematik, das Ergebnis von % negativer Zahlen eignet sich nicht als Array-Index!
• Jeder möge sich bitte Deklaration und Verwendung von argc und argv (und deren Reihenfolge!) nachhaltig ins Gedächtnis rufen (und laut Standard hat main als Returntype int (nämlich den Exit Status), nicht void wie unter Windows!)!
• Eine Funktion func ohne Parameter muß in C (nicht C++) rettype func(void) geschrieben werden, rettype func() ist verboten (bedeutet etwas anderes)!
  Das gilt vor allem für main ohne argc und argv.
• conio.h ist ein Windows-Spezifikum: Diesen Headerfile gibt es auf keinem Unix, und er steht auch nicht im C-Standard, also weglassen!
• Wer unbedingt von einem C-Programm aus den Terminal-Bildschirm löschen will:
  system("clear"); (Linux) bzw. system("cls"); (Windows)
  Das ist unter Linux aber eher unüblich!
• Wenn man String-Funktionen verwendet, sollte man auch string.h inkludieren!
• Ist jedem der Unterschied zwischen char *p; und char s[...]; ganz klar? Kommt jeder mit char **p; usw. zurecht?
• Ist jeder im Umgang mit Strings sattelfest (Stringfunktionen, Pointer-Arithmetik)?
• C verwandelt Strings, die eine Zahl enthalten, nicht automatisch in einen Integer, und auch i = (int)(s); leistet nicht das Gewünschte (es speichert die Adresse von s in i). Am besten atoi(s) verwenden!
• Zuweisung von Strings:
  • Mit = wird nicht der String selbst, sondern nur ein Pointer auf den String auf der rechten Seite zugewiesen. Die linke Seite muß daher ein char * sein, und keinesfalls ein char[]!
  • Will man wirklich den Inhalt des Strings, d.h. die Buchstaben, kopieren, muß man strcpy, strcat usw. (oder eine Schleife) verwenden. Dabei muß die linke Seite entweder ein char[] sein oder ein bereits initialisierter Pointer (auf einen Bereich, wo Platz für die Buchstaben ist!).
• Ist jedem der Unterschied zwischen sizeof und strlen klar?
  • sizeof liefert die Größe des Typs / der Variable / des Arrays (in Bytes, nicht Elementen).
    Das ist eine Konstante, schon beim Übersetzen, unabhängig vom Inhalt!
  • strlen liefert die Länge des aktuell im Array gespeicherten Strings
    (bis zum '\0').
• Bei der Deklaration von Arrays für Strings bitte \n und \0 bei der Größe berücksichtigen!
• Lokale Arrays variabler Größe (mit einem nicht konstanten Ausdruck in den [ ] in der Deklaration) sind nur in C, aber nicht in C++ möglich.
• Pointer auf lokale Daten (im Besonderen: Lokale Arrays und Strukturen)
  dürfen nicht als Returnwert zurückgegeben werden!
  (denn sie zeigen nach dem return auf nicht mehr gültige Daten)
  Stattdessen: Array oder Struktur für das Ergebnis im Aufrufer anlegen und übergeben!
• Bitte bei Ausgaben mit printf usw. nicht auf das \n vergessen!
• Beim Lesen von Eingaben mit scanf nicht auf das & bei den Argumenten vergessen!
  Ausnahme: char-Arrays und -Pointer für "%s" brauchen kein &, weil sie ohnehin schon ein Pointer sind!
  Weitere Fallen bei scanf:
  • scanf läßt alle Zeichen, die nicht zum Format passen, für den nächsten Lese-Aufruf über: scanf("%d",&n); läßt zum Beispiel ein nach der Zahl eingegebenes '\n' im Input stehen!
  • Mit scanf kann man nicht zwischen Leerzeichen und neuen Zeilen in der Eingabe unterscheiden: Zum Format "%lf %lf %lf" passen beispielsweise 3 Zahlen in einer Zeile genauso wie 3 Zeilen mit je einer Zahl und je einer Leerzeile dazwischen.
  • Mit "%s" kann man nur Strings einlesen, die keine Zwischenräume enthalten (es wird bis zum nächsten Zwischenraum gelesen)!
  • Normalerweise überspringt scanf automatisch Zwischenräume und Leerzeilen vor der eigentlichen Eingabe, bei "%c" aber nicht: Es wird das nächste Zeichen der Eingabe gelesen und in der Variable gespeichert, auch wenn es z.B. ein vom vorigen scanf übergebliebener Zeilenvorschub ist!
    Abhilfe: " %c" (mit Zwischenraum: Überspringt Leerzeichen und -zeilen)
  • "%e", "%f" und "%g" erwarten beim Ausgeben mit printf eine double-Variable, beim Einlesen mit scanf hingegen eine float-Variable: Zum Einlesen von double muß man "%lf" usw. verwenden!
  Betreffend Returnwert von scanf: man-Page genau lesen!
  Auf scanf nach Möglichkeit überhaupt verzichten!
  Alternative: fgets und atoi bzw. atof für Zahlen, fgetc für einzelne Zeichen.
  Ev. auch fgets gefolgt von sscanf, um genau eine Zeile zu lesen.
• Ein solides Programm prüft seine Eingaben und Commandline-Argumente (betr. Anzahl, Länge, Wert, ...).
• Nicht verwechseln: gets und fgets liefern NULL bei Ende des Files oder Fehler, getchar, getc und fgetc liefern EOF!
• Bitte die Unterschiede zwischen fgets und gets bezüglich \n nachlesen (analog für fputs und puts)!
  Mein Stil in den meisten Fällen: fgets verwenden (ist sicherer),
  \n sofort nach dem Einlesen händisch entfernen und beim Ausgeben wieder extra dazutun.
• Zum Erkennen des Dateiendes:
  • EOF ist eine Konstante (bei fast allen Systemen -1).
    Konstrukte der Art "while (f != EOF)" oder "while (!EOF(f))" sind daher völlig sinnlos!
  • feof(f) wird erst gesetzt, nachdem eine Lesefunktion das Fileende erreicht und mit Fehler geendet hat, und nicht schon dann, wenn erst der nächste Leseaufruf an das Dateiende stoßen würde.
    "while (!feof(f)) {fgets(..., f); ...}" funktioniert daher auch nicht!
  • Richtige Vorgangsweise:
    1. In der Schleifenbedingung lesen, bis die Lesefunktion einen Fehler liefert:
       Die Schleifenbedingung prüft den Returnwert der Lesefunktion je nach Funktion auf NULL oder EOF!
    2. Nach der Schleife eventuell mit feof(f) oder ferror(f) prüfen, ob das Lesen wegen des Dateiendes oder wegen eines echten Fehlers schiefging.
• Bitte folgendes Standard-Konstrukt zum zeilenweisen Einlesen und Verarbeiten von einer Datei f (für Terminal-Input stdin statt f) in eine Variable line (beispielsweise deklariert als "char line[LINELEN+2];": fgets braucht ein Array, keinen Pointer) im Schlaf zu beherrschen:

  while (fgets(line, sizeof(line), f)) {
    ...
  }
  

• Zur Erinnerung: Zwei Varianten zum Entfernen eines \n am Ende eines Strings line:
  1. line[strlen(line)-1]='\0';
  2. *strchr(line, '\n')='\0';
  (ist jedem klar, in welchen Fällen diese Varianten einen Absturz verursachen?)
• Bitte nachlesen und merken, wie man Strings, Arrays und Strukturen sowie beliebige Verschachtelungen davon gleich beim Deklarieren initialisiert!
• Strukturen als Ganzes zuzuweisen ist zwar zulässig (und funktioniert auch richtig), aber in den meisten Fällen nicht sinnvoll: Im Normalfall will man nur einen Pointer auf die Struktur zuweisen! Dasselbe gilt für Argumente und Returnwerte: Strukturen sind erlaubt, aber üblicherweise werden Pointer auf Strukturen übergeben!
• Arrays (und damit Strings!) kann man hingegen als Ganzes weder zuweisen noch vergleichen! (es werden nur die Adressen zugewiesen bzw. verglichen)
• Bei Zuweisungen innerhalb von Vergleichen (z. B. in if- oder while-Bedingungen): Immer Klammern setzen; ohne Klammern bewirken die Vorrangregeln das Gegenteil von dem, was man normalerweise haben will!!!
• Bitte in Header-Files keine Variablen deklarieren. Auch ausführbarer Code (außer Makro-Definitionen) hat in Headern nichts zu suchen. Headerfiles sind für Konstanten, typedef's, Funktionsprototypen usw..
• Bitte alle Aufrufe nicht-trivialer System- und Library-Funktionen sofort auf Fehler prüfen! Es ist in eurem eigenen Interesse, wenn das Problem sofort angezeigt wird und nicht unentdeckt bleibt und viele Programmzeilen später zu seltsamen Effekten führt!
• Ausgabe von Fehlermeldungen:
  • Wenn errno gesetzt ist, d.h. nach Aufrufen von System- und Library-Funktionen, die mit einem Fehler endeten: Mit perror oder strerror!
  • Wenn errno nicht gesetzt ist, z.B. nach falschen Eingaben oder zu wenigen oder zu vielen Argumenten beim Programmaufruf usw., ist perror sinnlos. In diesem Fall: Die Meldung mit fputs oder fprintf ausgeben, und zwar auf stderr, nicht auf stdout!
  • Wenn man einen internen Programmfehler oder eine unmögliche Situation entdeckt hat (und nur dann!): Sinnvollerweise mit assert (oder abort) abbrechen. Auf Benutzerfehler mit assert zu reagieren, ist unhöflich!
• Bitte bei einem exit immer einen sinnvollen Exit-Code angeben: 0 bei Erfolg und Werte zwischen 1 und 125 (und keine anderen!) bei Fehlern (nach einem Fehler soll man kein exit(0) machen!).
• Ich empfehle auch in main ein exit und kein return!
  Bitte das exit(0); am normalen Ende von main nicht vergessen!

Programmier-Richtlinien

• Kommentare:
  • Jedes Programm sollte mit einem Kommentar beginnen, der Autor und Kurzbeschreibung enthält.
  • Einen Kommentar zum Programmaufruf kann man sich sparen, wenn man gleich am Anfang den Usage-Message-Text als Konstante definiert, sonst gehört auch das in den Kommentar am Anfang.
  • Vor jeder nichttrivialen Funktion sollte ein Kommentar stehen:
    Was macht die Funktion, was geht rein, was kommt raus, was sind die Fehlerfälle?
  • Nicht offensichtliche Konstanten, Variablen und Datenstrukturen sind bei ihrer Deklaration zu kommentieren.
  • Lieber leicht verständlichen Code schreiben und nicht dokumentieren als umgekehrt!
• Stil:
  • Sprechende Namen für Variablen, Konstanten und Funktionen verwenden, nicht zu lang und nicht zu kurz (lokale Variablen eher kürzer, alles andere eher länger!).
  • Sinnvoll entsprechend der Befehlsschachtelung einrücken (einen Editor verwenden, der das gut kann!)!
  • Schließende } allein in eine Zeile, öffnende { nicht unbedingt.
  • Noch besser (weil alle Editoren diesbezüglich Schwächen haben):
    Das Programm hin und wieder mit einem Formatierprogramm formatieren:
    astyle, bcpp, indent, uncrustify, ...
    Ich empfehle UniversalIndentGUI, das einige dieser Programme unter einer netten grafischen Oberfläche verpackt!
  • Im Zweifelsfall lieber zu viele ( ) (bei unklaren Vorrangregeln, geschachtelten Zuweisungen, ...) und { } (bei geschachtelten if) als zu wenige!
• Allgemeines:
  • Für jede verwendete Library-Funktion ist der entsprechende Header zu inkludieren!
  • Wenn möglich vorhandene Library-Funktionen verwenden, nicht selbst das Rad neu erfinden!
  • Keine "magic numbers" irgendwo im Programm vergraben, und schon gar nicht dieselbe Zahl an mehreren verschiedenen Stellen!
    Jede derartige Konstante (Zeilenlänge, Arraygröße, math. Werte) wird am Beginn des Programms mit einem const ... oder #define festgelegt!
    #define-Konstanten schreibt man normalerweise groß.
  • Reihenfolge in jedem Programm:
    1. #include's
    2. #define's und const's
    3. typedef's
    4. extern's
    5. Globale Variablen
    6. Prototypen
    7. Funktionscode
    Punkte 1-6 niemals mitten im Funktionscode vergraben!
  • C99 und C++ erlauben Deklarationen mitten im Code sowie im Initialisierungsteil von for-Schleifen.
    Ich halte das für unklug, ich möchte auf einen Blick am Anfang einer Funktion sehen, welche Daten sie verwendet!
  • Jedes Programm sollte beim gcc mit -std=... -pedantic -W -Wall ohne Fehler und nur mit abgeklärten Warnings kompilierbar sein!
• Programmkonstrukte:
  • goto ist verboten!
  • break und continue sind prinzipiell erlaubt, ebenso andere unhübsche, aber allgemein verbreitete Konstrukte (Conditional Operator, Zuweisungen innerhalb von Vergleichen, ...). Jeder muß selbst entscheiden, ob sein Code leicht verständlich und nachvollziehbar ist!
  • Ein switch sollte immer ein default: haben, und sei es nur zur Ausgabe einer Fehlermeldung.
• Fehlermeldungen:
  • Jeder Funktionsaufruf, der einen Fehler liefern kann, sollte auch auf Fehler geprüft werden (bis auf einige wenige offensichtliche Ausnahmen, z.B. Schreiben auf stderr).
    Auch malloc ist zu prüfen!
  • Beim Programmstart ist auf die richtige Art und Anzahl von Argumenten zu prüfen und bei Fehlern mit einer Usage-Message, die den korrekten Programm-Aufruf erklärt, abzubrechen.
  • Weiters sind alle Benutzereingaben auf Korrektheit zu prüfen.
  • Jede Fehlermeldung ist auf stderr auszugeben, nicht auf stdout.
  • Jede Fehlermeldung sollte den Programmnamen (argv[0]) enthalten.
  • Jede Fehlermeldung nach einer Funktion, die errno setzt, sollte den entsprechenden Fehlertext enthalten (perror oder strerror).
  • Programminterne Voraussetzungen, unmögliche Programmzustände usw. mit assert prüfen!
  • Für falsche Benutzereingaben, I/O-Fehler und dergleichen ist assert hingegen nicht gedacht!