XhochY + CountCain + …

In der Schule nennen wir es Style Guide, bei den meisten opensource-Projekten heisst es Coding Standards, richtig wäre eigentlich Coding Style Guide, wie sich nach langer Recherche herausgestellt hat. Style Guides an sich sind nicht direkt auf Quellcode oder noch weiter Text festgelegt, sondern können auch z.B. die Maße eines Werbeplakates festlegen, würde man einen Schritt genauer gehen müsste man Text Style Guide sagen, jedoch bezeichnet man hier eher die Schriftart und die Papiergröße, was beim Programmieren nicht nötig ist, wichtiger sind hier Prä- und Suffixe der Variabeln(ungarische Notation) und die Einrückungen, die je nach Kommando gemacht werden, dies nennt man dann Coding Style Guide. English, ok man kann es übersetzen, ist eigentlich ja nicht unsere Unterrichtssprache, deshalb nenne ich es jetzt mal Kodierungsrichtlinien(keine eigene Erfindnung, sondern ganz nomaler Fachbegriff).Kernpunkt dieses Artikels ist, wie ich leider erschreckend feststellen musste, die beiden Familien von Kodierungsrichtlinien vorzustellen, die die ungarische Notation nutzen, wobei die erste aus dem Pascalumfeld kommt(lerne ich in der Schule) und die zweite, mehr verbreiterte (im opensource Bereich) eher bei C-Programmen genutzt wird. Bei C# und Java ist es heutzutage üblich die ungarische Notation größtenteils wegzulassen, da man hier kaum implizite Typumwandlungen und meistens gute IDEs mit Codevervollständigung hat.

Die erste, aus dem Pascalumfeld stammende Familie, wovon ich mein Wissen hautsäch von meiner Schule und Delphi Source habe. Hauptsächlich ist hier der Unterschied entstanden, da man in Delphi hauptsächlich mit GUI und ohne Groß-/Kleinschreibungsunterscheidung arbeitet.

• Einrückenungen werden normalerweise immer mit 2 Leerzeichen gemacht, wenn man einen neuen tieferliegenden Anweisungsblock anfängt
• Typen(so nennt man Klassen in Pascal) bekommen immer den Präfix T
• Die Namen der Funktionen und Prozeduren werden im CamelCase geschrieben
• Nach jedem Codeabschnitt wird eine Leerzeile eingefügt, sollten danach noch andere Anweisungen kommen
• Leerzeichen sollten so wenig wie möglich benutzt werden, jedoch sollten um einen Operator(ausgenommern () und []) herum immer 2 Leerzeichen sein
• Die Anweisung bzw der Anweisungsblock, der auf eine Schleife/Bedingung folgt muss immer in der nächsten Zeile beginnen, er darf nicht in der gleichen Zeile wie die Schleife/Bedingung stehen.
• begin und end stehen in ihrer Zeile immer allein
• zusammengehörende begin und end müssen untereinander stehen, d.h. sie haben die gleiche Anzahl an Einrückungen.
• Units werden mit uUnitname.pas abgespeichert und Projekte mit pProjektname.dpr
• Objektnamen von Komponenten beginnen immer mit dem ersten Buchstaben des Komponentennamens z.B. ein Edit-Objekt würde eTest heißen

Kritik: Vor allem der zu unklare Gebrauch von Präfixe ist hier sehr schwer zu unterscheiden. So würden Objekte vom Typ TCanvas, TComboBox und TCheckBox alle den Präfix c bekommen, besser wäre es wenn man hier längere Präfixe benutzt(z.B. can für TCanvas, chkb für TCheckBox und cob für TComboBox) oder sich auf die IDE verlässt, wobei dies bei Delphi und FreePascal immer gegeben ist. Die Dateien bräuchten meiner Meinung nach keine Präfixe, da man hier schon die Dateienungen pas und dpr hat, an denen man ihren Typ erkennt. Sonst muss ich sagen ist dies für Delphi/Pascal eine sinnevolle Kodierungsrichlinie, wobei ich mich hiermit nochmals bei meinem Informatiklehrer entschuldigen möchte für meine Kritik an ihr.

Die zweite Familie ist die C-typische Kodierungsrichtlinie, welche man fast überall in der opensource-Welt und auch in der C-ähnlichen-programmierenden Berufswelt antrifft, die Bekanntheit merkt man am häufigen Auftauchen in unterschiedlichen Progammierprojekten, so z.B die PHP-Erweiterungen PEAR und die opensource Initiative GNU. Hier ist sehr wichtig auf Groß- und Kleinschreibung zu achten!

• Im Gegensatz zur ersten Familie wird hier die { (= begin in Pascal) in der gleichen Zeile wie die Bedingung/Schleife geschrieben, sollte bei Bedingungen noch eine else(if)-Abfrage kommen, so wird } in diese Zeile geschrieben, z.B. } else {

• Funktionen werden auch im CamelCase geschrieben, jedoch ist der erste Buchstabe immer ein kleiner, z.B. funktionsName() => “BSD/Allman style”
• Bei Funktionen steht die { immer in einer eigenen Zeile
• Klassen bekommen immer den Präfix C
• Nach jedem Codeabschnitt wird eine Leerzeile eingefügt, sollten danach noch andere Anweisungen kommen
• Leerzeichen sollten so wenig wie möglich benutzt werden, jedoch sollten um einen Operator(ausgenommern () und []) herum immer 2 Leerzeichen sein
• Dateitypen werden durch ihre Endung bestimmt, eine zusammengehörende Header und Codedatei sollten aber gleich heissen, d.h. Klasse1.h und Klasse1.cpp
• Definitionen werden nur in Großbuchstaben geschrieben(#define ZAHL 1)
• Es gibt zwar nicht so viele Präfixe wie in der vorherigen Klasse, jedoch sind diese explizit vorbestimmt, weshalb ich sie hier aufzähle
• c für Variababeln des Typ char
• n für Ganzzahlen(short, int, long)
• f für Fliesskommazahlen(float, double)
• sz für C-Strings(char *)
• s für C++-strings(string)
• m_ für Member-Variabeln einer Klasse/Union/Strunktur
• g_ für globale Variabeln und Konstanten
• manchmal o für Objekte einer Klasse(sonst kein Präfix)
• manchmal b für boolsche Variablen(sonst n)
• a für Arrays, wenn in der Sprache vorhanden

Kritik: Die hier aufgeführte Liste ist sehr simpel, wer sich jedoch schon mal die Kodierungsrichtlinien macher opensource-Projekte durchgelesen hat, der hat festgestellt, dass diese meistens unüberschaubar groß sind. Eine objektorientierte Programmierung ist hier auch vorgesehen, jedoch wird nicht jeder Klasse ein Präfix zugewiesen, was simpler zu lernen ist, jedoch vllt zu Verwechslungen führen kann, ein Suffix könnte hier ausreichen(z.B. ein Edit-Objekt einer Form m_UsernameEdit). Das m_ und g_ wird meist als überflüssig betrachtet, jedoch ist es gerade bei OO-Programmierung hilfreich, wenn man eine globale und eine lokale Variable mit gleichem Namen hätte.

Hiermit möchte ich noch daraufhinweisen, dass ich hier nur auf die Teile der Kodierungsrichtlinien eingegangen bin, die den Quellcode direkt betreffen, jedoch nicht die Dokumentierung dessen.