Nun zur praktischen Seite vom Fehler vermeiden und Fehler suchen. Erstmal überhaupt Fehler vermeiden. Code Conventions, ganz vorne anfangen, mit dem Fehler vermeiden. Oder Coding Standards oder Style Guides.

Sie finden für das unzählige Begriffe. Man einigt sich auf bestimmte Standards, wie Programme zu schreiben sind.

Das sind alle Beteiligten in einem größeren Team. Das sind alle Beteiligten in einem größeren Team, die Programme schnell lesen können und schnell warten können. Haben Sie schon gesehen, dass wenn Sie C programmieren, dass Sie unzählige Möglichkeiten haben. Wo setzen Sie die Klammern hin, wie nennen Sie die Variablen usw.

Der C-Compiler nimmt nicht alles, aber er nimmt doch sehr viel. In so einem Style Guide oder Code Conventions schreibt man typischerweise fest, insbesondere für Team-Projekte, wie denn die Details aussehen sollen.

Damit ist immer noch nicht alles hundertprozentig festgenagelt, aber es wird schon etwas besser. Es fängt an mit formalen Standards. Zum Beispiel solche. Es kann sein, dass es so lautet in den jeweiligen Code Conventions, es kann sein, dass es anders ist.

Zum Beispiel könnte man Folgendes haben, dass Variablen ausführlich auf Englisch benannt sind. Ausführliche englische Namen für Variablen. Das könnte zum Beispiel in Code Conventions stehen.

Benamungsvorschriften. Irgendwie sagen die Leute lieber Benamungsvorschriften statt Benennungsvorschriften. Ausführliche englische Namen für Variablen. Das habe ich ja im Seminar und im Praktikum auch immer so gehalten. Keine komischen Kürze, die man nicht verstehen kann, sondern immer lang ausgeschrieben.

Solche Geschichten statt Current Item. Man kann sie auch Ci schreiben und Number of Values. Man kann sie auch Nv schreiben. Aber wissen Sie drei Tage später noch, was das war? Wissen Ihre Kolleginnen und Kollegen drei Tage später noch, was das war?

Eine von den heute üblichen Regeln. Kann sein, dass es eine andere gibt, aber das ist eine von den heute üblichen Regeln. Obendrein wird man so etwas noch festlegen. Zum Beispiel, wie ich es jetzt geschrieben habe, ist die sogenannte Camelback Notation.

Oder soll ich sagen, Camelback Notation. Ich soll erst einmal sagen, was Camelcasing ist. Das haben Sie auch schon häufiger gesehen. Camelcasing ist, wenn ich den ersten Buchstaben groß schreibe und dann den Buchstaben von jedem nächsten Wort groß schreibe.

Ohne Leerzeichen. Current Item Price. Das sieht man auch gerne in der Werbesprache. Oder bei Produktnamen sehen Sie das gerne. Mitten drin groß geschrieben und den ersten auch groß geschrieben. Das nennt sich Camelcasing. Camelcasing gegen der Kamele in der Wüste. Als ob eine Karawane von rechts nach links durchs Bild geht.

Camelcasing, das ist das erste Kamel, das ist das zweite, das dritte. Ich weiß nicht, wer darauf gekommen ist. Das ist ein bisschen sehr weit hergeholt, aber so soll es sein. Camelback Notation ist, den ersten klein zu schreiben. Das macht man typischerweise für Variablen.

Und alle folgenden Wörter direkt anschließend mit Großbuchstaben. Sowas könnte in Code Conventions stehen. Und bei den Variablennamen könnte obendrein stehen, kurze Namen. Okay, für lokale Variablen mit sehr geringer Reichweite.

Da können wir auch noch kurze Namen haben. Kurze Namen allenfalls für lokale Variablen. Ich schreibe jetzt den Rest nicht in, mit sehr kurzem, mit sehr kleinem Scope. Mit sehr geringer Sichtbarkeit für lokale Variablen.

In der Vorschleife lohnt es sich vielleicht doch nicht, das I auszubuchstabieren. Man lässt es dann vielleicht doch als I, wenn in der Vorschleife nur zwei, drei Zeilen drinsteht. Nicht, dass Sie es I nennen, Item oder Member oder Person, Channel, Sample.

Das könnte man ja auch sagen, wenn Sie überall sowas vor, nicht zu abschreiben. Vor Int Sample gleich Null, Sample kleiner gleich Sample plus plus und so weiter. Man würde sich die Fingerwunsch tippen. Gut, mit den modernen Entwicklungssystemen nicht, weil das automatisch ergänzt würde. Aber es ist trotzdem viel zu lesen. An der Stelle würde man dann doch vielleicht vor Int S schreiben, statt Sample auszubuchstabieren.

Für lokale Variablen mit sehr geringer Sichtbarkeit, vielleicht dann doch kurze Namen. Sowas könnte in Code Conventions stehen. Andere Geschichte wäre, die man üblicherweise findet, Funktionen in Befehlsform.

Imperativ, natürlich auch dann wieder auf Englisch im Zweifelsfall. Befehlsform, also eine Funktion, wenn das jetzt Deutsch wäre, eine Funktion Größe oder Art.

Gäbe es nicht, das ist nicht Befehlsform. Eine Funktion müsste dann heißen, gibt Größe, Sätze Größe, hohle Art, Sätze Art. Immer in Befehlsform oder im Englischen dann auch nicht zu mitschreiben. Jetzt noch als Beispiel sowas wie Get Size, Get Size oder Write Line, Put Character.

Haben Sie auch schon irgendwo gesehen. Ich würde es dann sogar ausschreiben, anders als klassisches C. Put Character, alles in Befehlsform. Das wäre üblich für Funktionsnamen. Ist aber Konvention.

Das heißt, man kann auch hingehen und sagen, ok, alle Funktionen müssen in Großbuchstaben benannt werden auf Deutsch. Und bitte immer Substantive, könnte man auch sagen. Hat sich einfach eingebürgert. Dem Compiler wäre es egal. Es wäre vielleicht nur schlechter zu verstehen.

Dann kommen solche Sachen wie, vor jeder Funktionsdeklaration eine Beschreibung. Das ist dem Compiler auch relativ egal. Was heißt relativ? Das ist dem Compiler auch egal. Vor jeder Funktionsdeklaration eine Beschreibung. Ich will sagen, ein Kommentar, der grob sagt, was diese Funktion tut.

Auch nicht zum Abschreiben, nur gerade als Demo hier. Also wenn Sie eine Funktion haben, Int, Get Size, Void, davon die Deklaration. So eine Funktion, Deklaration.

Dass Sie dann davor sitzen, Get Size tut dieses oder jenes und gibt dann folgendes Ergebnis zurück. Jetzt Minimal. Gesundheit. Würde man häufig haben in Code Conventions, dass vor jeder Deklaration stehen muss, was die Funktion denn im Einzelnen tut.

Dafür gibt es auch noch schöne Verfahren, dass das ganze automatisch formatiert werden kann. Hab ich nie vorgeführt. Wenn Sie googeln wollen, Docsigen. Docsigen. Dass automatisch aus diesen Kommentaren nachher Dokumentation erzeugt wird.

Klein Kram. Scheinbar Klein Kram. Wie Schweifklammern in eigene Zeile. Darüber gibt es verschiedene Ansichten. Eigenen Zeilen sollte ich mal schreiben.

Darüber gibt es verschiedene Ansichten. Es gibt Leute, die schreiben If, Bedingung, Schweifklammer auf, bla bla bla bla, Schweifklammer zu. Und es gibt Leute, die schreiben If, Bedingung, Schweifklammer auf, bla bla bla, Schweifklammer zu. Lassen die beiden üblichen Arten es zu machen. Sie können es natürlich auch komplett anders machen.

Sie können auch fordern, dass dazwischen drei Zeilen freigelassen werden müssen. Oder dass die Schweifklammer da hinten stehen muss. Wie auch immer. Der Compiler wird es fressen. Es wird keiner mehr verstehen, aber der Compiler wird es fressen. Sowas würde man nicht fressen. Das liegt man garantiert fest in Code Conventions. Wo stehen die Schweifklammern?

Und dann natürlich die Einrückung erst recht. Den Compiler ist das auch egal, wie sie einrücken. Oder ob sie überhaupt nicht einrücken. Also wenn Sie hier sowas schreiben wie int a ist gleich 7, if, na, nein, blöd.

Sowas. If a ist gleich 8, dann setze ich a 6.

Warum nicht so? Warum nicht so? Könnte man ja alles tun. Wenn Sie ganz hart drauf sind, setzen Sie das if auf die Zeile davor. Oder Sie schreiben das Programm komplett in einer Zeile. Alles auf eine Zeile. Der Compiler wird das nehmen. C ist da sehr großzügig. Andere Sprachen sind da nicht so großzügig. Die verlangen, dass die Formatierung so halbwegs zumindest passt.

Es gibt Sprachen, bei denen zum Beispiel hier diese Einrückung wichtig ist. Statt der Schweifklammer dann die Einrückung wichtig ist. Netterweise kann man in den meisten modernen Entwicklungssystemen einfach sagen, räum mal auf. Hier wäre das or-indent.

Und das passt dann von selbst. Hier ist das noch relativ schlicht. In den größeren Entwicklungssystemen könnte man dann tatsächlich selbst definieren, ob die öffnenden Klammern hinter das if, hinter das if gehören. Oder auf die nächste Zeile. Wie viel Abstand jeweils zu lassen ist. Ob irgendwelche Lärzeilen einzubauen sind. Und so weiter und so fort. Ist hier Abstand zu lassen, um das Gleichgleich.

Ist hier, um dieses Gleichabstand zu lassen. Diese Entwicklungsumgebung macht das nicht automatisch. Die größeren Entwicklungsumgebungen machen dann auch sowas automatisch. Das heißt, man muss es gar nicht mehr aufschreiben als Code Conventions. Sondern man liefert eine Schablone mit. Für die dann etwas komplizierter Funktion, die nicht einfach nur or-indent ist, sondern Autoformatierung ist.

Und die Maschine macht das von selbst so, wie es vorgeschrieben ist. Das ist dann etwas einfacher anzuhaben. Und dann das letzte hier zu den formalen Sachen.

Boilerplate-Kommentare finden Sie in den meisten Professionellen natürlich auf freien Programmen. Das am Anfang erstmal großartig steht. Am Anfang jeder Datei erstmal großartig steht. Dieses ist sowieso, sowieso geschrieben von diesen und jenen. Copyright, Haftungsausschuss und so weiter.

Das wäre ein Boilerplate. Jeweils 20-30 Zeilen Kommentare zu Beginn jeder Datei. Rein formale Sachen. Das würde man standardisieren in Code Conventions.

Und einschließlich Change Logs. Log wie Logbuch. Die Aufzeichnungen. Die Änderungsaufzeichnungen. Am so und sovielten, so und sovielten wurde die Funktion Blah hinzugefügt von XY und so weiter.

Das würde man auch alles oben reinschreiben standardmäßigerweise. Auch wenn man das heute eigentlich auf andere Warten noch rauskriegen kann aus Code-Management-Systemen. Das als Idee, was formal in solchen Code Conventions drinsteht. Sie kriegen, wenn Sie irgendwo als Programmierer tätig sind,

einen dicken Stapel DIN A4 oder eher ein PDF auf den Schreibtisch. Auf den elektronischen Schreibtisch, in dem das alles steht. Das ist dann zu beachten für alles, was Sie tun. Das sind die formalen Vorschriften. Beispiele für formale Vorschriften. Und dann gibt es Vorschriften gegen fehlträchtige Konstruktionen.

Zum Beispiel, dass man verlangt, dass Variablen sofort initialisiert werden. Das ist ja in C und C++ ein Drama. Außer bei den statischen Variablen, die einfach auf Null stehen.

Aber alle anderen stehen eben nicht auf Null. Variablen sofort initialisieren. Wenn Sie hier einfach nur int A hinschreiben. Das ist nicht garantiert, auf welchem Wert diese Variable A zu Beginn steht.

In C und C++ ist das nicht garantiert. In Java und C Sharp gäbe das einfach eine Fehlermeldung. In C++ und C sollten Sie sinnvollerweise immer sofort initialisieren. Dass Sie sicher sein können, was denn drin steht.

Das schreibt man in praktisch jede Codeguideline rein. Variablen sofort initialisieren. Das andere, was praktisch überall drin steht, dass man if und schleifen nur mit Schweifklammern verwenden darf.

Auch wenn der Compiler es anders nimmt. Das habe ich Ihnen nie verraten. Aus gutem Grunde. Sollte ich Ihnen das auch nie verraten. Wenn in dem if nur eine Zeile steht, dann können Sie die Schweifklammern weglassen. Das ist aber höllisch gefährlich.

Wenn jetzt jemand dazuschreibt und sagt, danach möchte ich gerne noch... Was mache ich jetzt mal sinnvollerweise? Jetzt habe ich A kaputt gemacht. Dann bestelle ich A plus gleich 5. Oder 4. A plus gleich 4. Wenn jetzt jemand sagt, jetzt schreibe ich das noch dazu. Das soll auch passieren, wenn A gleich acht ist.

Das ist pech gehabt. Dieses if, wenn es wahr ist. Wenn die Bedingung wahr ist, führt das if die Zeile aus. Wenn die Bedingung falsch ist, springt das if sofort dahin. Wenn Sie beim if die Schweifklammern weglassen, gilt die nächste Anweisung als das, was in Schweifklammern steht. Das ist heimtückisch, wenn man später was dazuschreibt.

Deshalb findet sich das überall als Pflicht in solchen Guidelines, if und entsprechend bei den Schleifen, weil und vor, die immer nur mit Schweifklammern zu verwenden. Dass man sieht, welcher Teil denn jetzt in der Schleife ist. Beziehungsweise bei dem if, in welchen Teil reingereicht wird oder nicht.

If und Schleifen immer mit Schweifklammern. Niemals Zuweisungen. Auch eine ganz übliche Guideline. Niemals Zuweisungen in if.

Das ist auch beliebt, aber heimtückisch. Sie können hier sowas haben. Ich mache folgendes. Ein praktisches Beispiel wäre dieses hier. Ich möchte einen Zeiger bauen.

Ich bin nicht in C-Sharp, sondern in C. Ich möchte einen Zeiger bauen. Dann machen wir jetzt folgendes.

Ich hole mir einen neuen Speicherplatz. Von mir aus 13 mal size of int. Da muss ich den hier casten. Oh, p muss da stehen, Entschuldigung. So wird das funktionieren. Auf folgende Gedanken könnte man kommen.

Das sehen Sie auch in sehr viel Software. Ist aber doch ein bisschen gefährlich. Also ein Zeiger. Ich möchte diesen Zeiger jetzt mit der Adresse von 13 Integers füllen. Das hier ist die Anweisung. Reservieren mir Speicherplatz für 13 Integers.

Und die Adresse von dem reservierten Speicherplatz bitte nach p. Wenn Sie jetzt ganz hart drauf sind, können Sie das so verkapseln. If, das hier. Das if, wenn man das so anwendet, prüft, ob das was drin steht ungleich Null ist. Wenn diese Speicherreservierung funktioniert, gibt es einen Zeiger, der ungleich Null ist.

Der wird in p geschrieben. Und das if prüft dann, ob dieser Zeiger, der da angekommen ist, ungleich Null ist. Ob das, was hier in p steht, ungleich Null ist. Wenn das ungleich Null ist, ist alles klargegangen und ich kann damit weiterarbeiten. Das sehen Sie ganz häufig, diese Art Konstruktion. Vermeiden. Ich hoffe, es ist sofort klar, dass das sehr unübersichtlich ist.

Vermeiden. Typischerweise steht in diesen Guidelines keine Zuweisung. Das hier ist eine Zuweisung. Kein Vergleich, sondern wirklich eine Zuweisung. Reserviere den Speicher und die Adresse weise zu an p. Zuweisungen in ifs verboten.

Das steht typischerweise in den Guidelines drin. Da kann man deutlich leichter verstehen, was da passiert. Und viertes und letztes, was man hin und wieder liest. Ganzzahlvariablen nur in definierter Größe.

Das habe ich ja auch schon häufiger erwähnt. In C++ ist nicht klar, wie groß ein Integer ist. Ein Integer muss mindestens so groß sein, wie ein Byte. Aber ob der nun ein, zwei, drei, vier oder acht Byte hat, weiß man nicht.

Das kann von Maschine zu Maschine schwanken. Auf dieser Maschine mit diesem Compiler ist der Integer sehr groß. Zwei Byte groß. Auf anderen Maschinen darf der auch mal gerne vier Byte groß sein. Sehr unschön, wenn man Programme auf der einen Maschine schreibt, oder mit dem einen Compiler schreibt, und dann einen anderen Compiler verwendet,

eine andere Maschine verwendet, wo das anders ist. Plötzlich funktioniert es nicht mehr. Wenn man nicht aufgepasst hat, dass es mal kleiner oder größer werden kann. Deshalb gerne auch mal diese Anweisung in den Guidelines. Das heißt, Int und Long und Short sind tabu, weil ich deren Größe nicht kenne.

Ich verwende gefährlich nur Variabletypen, deren Größe festgelegt ist. Die hatte ich mal am Rande erwähnt, so etwas hier wie Int 16 Type. Den hier zum Beispiel. Wenn Sie den verwenden statt Int, können Sie sicher sein, das Ding hat 16 Bit, zwei Byte.

Nicht mehr und nicht weniger. Die modernen Sprachen funktionieren alle so, das heißt, Java und C Sharp funktionieren zumindest so, dass da Int und Short und Long genau ausbuchstabiert sind. Der Long hat dann immer 64, der Int hat dann immer 32,

und der Short hat dann immer 16. Da hat man diesen Ärger nicht. Aber in C und C++ hat man diesen Ärger, dass Int das ist, was die jeweilige Maschine gerade gut kann. Wenn die jeweilige Maschine ein 16-Bit-Rechner ist, eben 16 Bit, und wenn die jeweilige Maschine ein 32-Bit-Rechner ist, eben typischerweise 32 Bit als Int.

Gibt es mit Java und C Sharp dann nicht mehr. Und Guidelines würden typischerweise vorschreiben, dass man da vorsichtig sein muss. Tja, irgendwie ist der VPN heute nicht willig.

Die Links stehen im Skript, was ich Ihnen zeigen wollen, gewollt haben würde, wären einmal die GNU Coding Standards, also alles aus der Ecke Linux und Konsorten,

wird sich zum Beispiel daran halten. Und was ich Ihnen auch noch eigentlich zeigen wollte, ist der Google C++ Style Guide. Da finden Sie Seite um Seite solche Vorschriften aufgelistet.

Ist egal, ich habe Ihnen ja schon ein paar von diesen Vorschriften gezeigt. Links stehen im Skript. Das sind nicht die einzigen beiden, bei Live nicht, aber die sind zum Beispiel frei verfügbar. Man kann sie mal inspirieren lassen, eine Idee kriegen, was es heißt, schon formal Fehler zu vermeiden

und Programme lesbar zu machen für andere Leute, für einen selbst lesbar zu machen und für andere Leute lesbar zu machen. Und dann gibt es noch ein paar spezifischere Angaben. Wenn Sie sich zum Beispiel Windows Programme angucken, klassische Windows Programme angucken,

finden Sie solche Bezeichner wie LPSZ Menu Name. Steht dem Text nicht zum Abschreiben. Solche Bezeichner finden Sie. Oder Sie finden so einen Bezeichner wie DW Style,

eine klassische Windows Programmierung. Das nennt sich die ungarische Notation von Herrn Simoni, dem Ungaren bei Microsoft. Sie haben vielleicht mitgekriegt, dass er irgendwann jüngst auf der Mir.

Eine von den Leuten zumindest, die sich den Flug ins Weltall gegönnt haben, der Herr Simoni. Vorher hat er als eine von vielen Taten diese Art von Benamung eingeführt bei Microsoft, die ungarische Notation. Die ganzen klassischen Windows Geschichten sind alle so mit solchen Namen bezeichnet.

DW Style heißt zum Beispiel Double Word Style. Damit ist gemeint, Doppelwort soll heißen 32 Bit. Ein Wort ist für Windows 16 Bit, ein Doppelwort in 32 Bit. Hiermit sage ich, die Variable Style ist 32 Bitig.

Der Typ steht im variablen Namen drin. Das schien mal eine gute Idee zu sein. Das macht man heute nicht mehr, aber es schien seinerzeit mal eine gute Idee, den Typ im variablen Namen mit anzugeben. Und dieses hier ist ganz heftig. Das ist ein Long Pointer auf einen String. Zero Terminated, Null Terminated. Auf einen C String.

Einen, der mit der Null aufhört. Ein langer Zeiger auf einen String, der mit der Null aufhört. LPS Set. Alle möglichen Strings finden Sie dann mit solchen Namen. LPS Set, bla, LPS Set, blub. Und tausend andere von diesen Sachen. Nicht wundern, wenn Sie mal Windows-Programme aufmachen. Diese Vorsilben kodieren,

was für ein Typ Variable das jeweils ist. Kann man tun, hat sich irgendwie nicht als so sinnvoll herausgestellt. Auch Microsoft macht es nicht mehr. In C Sharp ist das auch nicht mehr üblich. Aber sobald Sie klassisch Windows programmieren, sehen Sie solche etwas eigenwilligen Variablen Namen.

Die ungarische Mutation. Noch ein Beispiel für etwas spezifischeres ist MISRA. Das finden Sie zumindest zum Angucken. Hier auch in der Embedded Workbench.

MISRA ist ein Automobilindustrieverband. Wie schreibe ich Software für die ganze Automatik im Auto? Für das System, das die Bremsen steuert? Oder für das System, das die Scheinwerfer steuert? Schreibe ich natürlich im Zweifelsfall auch in C.

Und da möchte ich natürlich schon, dass das nicht abstürzt, sondern wirklich super sicher geschrieben ist. Deshalb ganz strenge Vorschriften. Hier sehen Sie ganz strenge Vorschriften von diesem Verein MISRA. Eine Vereinigung von Automobilfirmen. Und entsprechender Softwareindustrie.

Dutzendweise Vorschriften, die in diesem Fall, das sehen Sie, hier automatisch geprüft werden können, können verlangen, dass der Compiler von selbst prüft, dass alles Mögliche hier beachtet wird. Der nackte C-Compiler, dem wäre das alles egal.

Aber Sie können fordern, dass der Compiler pingeliger wird. Das sind die MISRA-Vorschriften aus der Automobilindustrie. Aber warum soll man sie nicht woanders verwenden? Und abschließend, ohne Internetzugriff jetzt auch nicht so ganz spannend.

Das Gegenbeispiel ist der International Obfuscated Sea-Code-Contest. International Obfuscated Sea-Code-Contest.

Was für ein Name. Link im Skript. Da können wir uns ja leider nicht ansurfen. IOCCC. Bei diesem Wettbewerb geht es darum, unlesbare C-Programme zu schreiben.

Obfuscated. Dunkel. Wie sagt man jetzt auf Deutsch? Unklare, verwirrende C-Programme zu schreiben. Wie kann ich ein C-Programm schreiben, bei dem ich überhaupt nicht erkennen kann, was es tut, oder bei dem ich sogar glaube, es tut was anderes, als es tatsächlich tut? Die beiden Beispiele, die ich verlinkt habe, das eine Beispiel,

sieht so aus, als ob es Primzahlen berechnet. Wenn Sie den Link aufmachen, finden Sie ein Programm, das auf den ersten Blick Primzahlen berechnet. Wenn dieses durch jenes teilbar ist, tue dieses oder jenes. Das Programm macht aber etwas völlig anderes. Es ist eigentlich ein Kryptografie-Programm.

Das andere Programm, das ich verlinkt habe, das hat die beiden netten Variablen Char-Li und die Variabel Char-Lotte. Es ist ein Briefwechsel zwischen Char-Li und Char-Lotte, der sich tatsächlich übersetzen lässt. Das Programm tut nichts Sinnvolles, aber man kann es wirklich lesen und sogar übersetzen.

Leider macht es nichts Sinnvolles. Von der Sorte finden Sie endlos bei diesem obfuscated C-Code-Kontest Programme in irgendwelchen geometrischen Formen, die selbst wieder diese geometrischen Formen reproduzieren. Das ist nun wirklich das Gegenstück zu sauberem, verständlichem Code.

Das Ziel hier ist, Code zu schreiben, der gerade nicht verständlich ist. Kann man sich mal angucken als Idee, was man vermeiden muss im Alltag? Solche Programme sollte man bitte nicht schreiben im Alltag.