Thiemos Archiv
- Sunday, 2005-11-27 13:20
- Ich wurde auf den lehrreichen Artikel »The Top 10 Ways to get screwed by the C programming language« hingewiesen und habe im Folgenden versucht, meine mit der Zeit erarbeiteten Regeln zur Vermeidung solcher Fehler zu notieren. Habe ich etwas vergessen oder durcheinander gebracht?
- Nicht abgeschlossene Kommentarblöcke sind in jedem Editor mit Syntax-Highlighting leicht aufzufinden.
- Das Vertauschen der Zuweisung
=und des Vergleichsoperators==ist in sehr vielen Programmiersprachen ein Problem. Oft wird empfohlen, wann immer möglich den konstanten Ausdruck an die erste Stelle zu schreiben, also z.B.if ("C" == sprache)anstatt des gewohntenif (sprache == "C"). Tippfehler wie in"C" = sprachelässt der Compiler nämlich nicht zu. - Der Denkfehler im gezeigten Beispiel ist, dass
bkeine Variable sondern ein Platzhalter ist. Dem Casting-Operator muss also unbedingt eine Klammer folgen:a = (char)(b). - Die Möglichkeit, mit
#defineSprachkonstrukte umzudefinieren, war schon immer tödlich:#define + -. Das ist tatsächlich ein Fehler in der Sprache, wenn man so will. - Wenn der Compiler sich nicht mit »nicht alle Programmpfade geben einen Wert zurück« meldet, sollte man über einen Wechsel nachdenken.
- Dass der Wechsel der »Endian«-Eigenschaft diverse Seiteneffekte mit sich bringt, soll offenbar ein »Feature« der Sprache sein, das man auf die eine oder andere Art wahrscheinlich sogar umgehen kann.
- Wer so etwas Fehlerträchtiges konstruiert und sich auf die Abarbeitungsreihenfolge von Funktionsparametern verlässt, hat es ehrlich nicht besser verdient.
- Es ist zu empfehlen, die zu
if,whileusw. gehörenden geschweiften Klammern grundsätzlich zu setzen, auch wenn sie nur eine einzige Codezeile beinhalten. Außerdem ist die Schreibweise vorzuziehen, bei der die Klammern ausgerichtet untereinander stehen. Das beansprucht zwar jedesmal ein bis zwei Zeilen mehr, ist aber ganz erheblich übersichtlicher. - Manchmal ist C wirklich merkwürdig.
- Die Variable wird verworfen, sobald ihr Gültigkeitsbereich (Scope) verlassen wurde. Korrekt wäre es, den benötigten Speicher mit
mallocdauerhafter zu reservieren. - Merkwürdig ist das schon, da man annehmen sollte, dass der Präfixoperator
++zu allererst ausgeführt wird. Aber auch hier gilt: Wer etwas so Fehleranfälliges schreibt, hat es nicht anders verdient. - Ein vernünftiger Compiler zeigt uninitialisierte Variablen an. Spätestens ein schrittweiser Durchlauf mit dem Debugger dürfte schnell zeigen, dass
beinen ganz merkwürdigen Wert beinhaltet. - Auch hier genügt ein einfacher Debugger-Durchgang, um den tatsächlichen Wert der vermeintlichen Konstante anzuzeigen.
- Typisch für C.
- Seltsam, aber wahr. Die Obergrenze eines Arrays wird nirgends implizit notiert, das muss man selbst tun.
- Die Interpretation von z.B.
010als Oktalzahl sorgt immer wieder für Erstaunen, weil dieses »Feature« der Sprache praktisch nie benötigt wird. Hier hilft nur eine gute Kenntniss der Sprache und sorgfältiges Debuggen. - Dass es vorzeichenbehaftete Zeichen (Char) gibt, ist wirklich seltsam. Auch hier ist es ganz einfach wichtig, seine Sprache zu kennen.
Kommentare zu diesem Beitrag können per E-Mail an den Autor gesandt werden.
zu 2.) Guter Tipp.
Zu 4.) Eine Präprozessordirektive mit einem Semikolon abzuschließen ist in (fast) jedem Fall tödlich. ;)
2) Nette Idee, stört aber die Lesbarkeit. Und das es keinen boolschen Datentyp in C gibt sollte eigentlich jeder C-Nutzer wissen...
3) Allgemein sind C++-Erweiterungen wie typisierte Konstanten und Inlinefunktionen dem Preprozessor vorzuziehen.
8) Wer auf Klammern verzichtet sollte sich bewußt sein, daß der Block nur aus einer Zeile besteht. Besserer Styleguide: Wenn auf Klammern verzichtet wird, die komplette Bedingung samt auszuführendem Block in eine Zeile setzen.
10) Bei den Standarddatentypen gibts nun einmal weder GarbageCollection noch Referenzzähler, das gehört ebenfalls zum Basiswissen.
13) Das ist nun einmal der Preis dafür, wenn man nicht explizit nichtlokale Bezeichner via global, uplevel, etc. importieren will. Läßt sich vermeiden, indem man nicht für jeden Kram dieselben 08/15-Bezeichner verwendet.
14) Seit C99 gibt es weitere Datentypen mit garantierter Bitzahl bzw. garantierter minimaler Bitzahl.
15) Arrays in C sind nun einmal genau wie Strings nichts anderes als Zeiger. Auch das ist Basiswissen.
16) Das ist tatsächlich eine bescheuerte und schnell vergessene Eigenschaft. Vor allem deswegen, weil Binärzahlen selbst fehlen.
17) Es gibt eigentlich gar keinen speziellen Zeichentyp in C. Ein char ist nichts weiter als ein Typ für Zahlen mit einem sehr kleinen Definitionsbereich. Entsprechend kann man auch damit rechnen, z.B. char irgendwas='C'+23; oder großakleinadifferenz='A'-'a';