cpp0a0.png
Edit v1.361 from 2005-03-29 to 2019-07-24 by HSc+SBa+TSc

Konventionen für C++

Wollen Sie im Team programmieren, sind Regeln der Zusammenarbeit gefragt. Eine ist die Schreibweise von Variablen und Objekten in Quelltexten. Wie diese bei H&S<-EDV erfolgt, wird nachfolgend beschrieben.

Wichtiger Hinweis: Diese Seite ist noch nicht fertig, dient allerdings als Beispiel, wie wir Artikel in das NOOP!-Framework einpflegen.

Konvention für den Aufbau von Quelltexten in Die Benennung mittels [Präfix]Typkürzel[Basisname[Suffix]]
Edit v1.400 from 2005-03-29 to 2019-07-08 by HSc+SBa+TSc

Konventionen für den Aufbau von Quelltexten

Header und Source

Das tolle bei C und C++ ist, das es eine klare Trennung zwischen Deklaration (Header) und Implementation (Source) gibt. Diese Trennung kann man sich für viele Vorteile zu nutze machen.

Prinzipiell gilt, zu jeder C bzw. CPP-Datei sollte es auch eine H bzw. HPP-Datei geben. Zudem sollte man auch nur Header inkludieren. Die Header selbst sollten so wenig wie möglich andere Header inkludieren, siehe Stichwort Forward declaration. Wenn man dies beachtet, hat man bereits viel gewonnen. Hier einige Beispiele warum, weshalb, wieso:

  • Source-Dateien müssen nicht inkludiert werden (Wer macht sowas?).
  • Vermeidung eines Chaos mit dem Schlüsselwort extern, d.H. (ja ein schlechtes, gesponnenes Beispiel) wenn man 30 globale Variablen nutzen möchte und diese keine Deklaration in einer Header-Datei haben, müssen diese 30 Variablen jedes mal mit extern benannt werden. Noch schlimmer wenn man 3 dieser Variablen aus irgendeinen Grund vom Aufbau her ändern muss, dann muss diese Änderung an jeder Stelle vorgenommen werden, wo die Variable benutzt wird.
    Stattdessen: Eine Header-Datei mit den gewünschten Variablen als "extern" deklarieren. In der gleichnamigen Source-Datei diese implementieren, bzw. initialisieren. Dann braucht man nur noch den entsprechenden Header inkludieren und kann auf diese Variablen direkt zugreifen.
  • Vorteile bei der Geschwindigkeit des Compilers und Linkers, vor allem spürbar, wenn Mehrkern-Kompilierung möglich und aktiviert ist.
  • Besseres Projektmanagement. Der "Vorgesetzte" in einer Gruppe von Programmierern, könnte z.B. mittels der Header-Dateien schon die Struktur vorgeben. Die Programmierer können dann die Implementation der Funktionkörper delegiert bekommen, bzw. unter sich aufteilen.

Header Input Process Output (HIPO)

Sie ist eine der ersten Art und Weisen, wie Quelltexte dokumentiert werden sollen.

In C++ lässt sich dieses Verfahren immernoch anwenden. Allerdings schreibt man diese besser nicht mehr in die Source-Dateien, sondern in die Header-Dateien. Der Grund dafür ist folgender, da in Header-Dateien im Prinzip die Schnittstellen definiert werden, kann man dort auch den HIPO-Kommentar hinpacken. Die Header beschreiben quasi genau das gleiche, was wir mit den HIPO-Kommentaren machen. In den Source-Dateien schreibt man dann nur noch die Kommentare innerhalb einer Funktion. Zu jeder Source-Datei sollte es immer eine Header-Datei geben.

Vorteil
  • Sie ist in jeder IDE anwendbar. Im Zweifelsfall kann man diese auch in einem einfachen Editor wie Notepad immernoch lesen.
  • Sie funktioniert komplett manuell, d.H. auch ohne IDE kann man diese benutzen.
  • Die Dokumentation/Kommentation ist zusammen mit dem Programmcode an einem Ort (Lokalität).
  • Die Erläuterung, was der folgende Quelltext realisieren soll, was er übergeben bekommt, was er intern gebraucht und was er zurück gibt, steht direkt vor dem Quelltext!
Nachteil: Sie streckt den Quelltext, allerdings lassen diese sich in moderneren Entwicklungsumgebungen auf und zuklappen.
Als zusätzlicher Nutzen ergibt sich daraus
  • abgegrenzte Funktionen,
  • einfache Datenschnittstelle und
  • Geheimhaltung der Wirkungsweise durch Übergabe der Art und Weise des Funktionsaufrufs und den Kommentarkopf.
Beispiel:
/******************************************************************************
 * Dateigroesze ermitteln durch                                               *
 * - Sichern der aktuellen Position,                                          *
 * - Springen zum Dateiende um die Groesze auszulesen und                     *
 * - Zuruecksprung zur gesicherten aktuellen Positon.                         *
 * Edit v1.102 from 2009-06-05 to 2009-09-21 by HSc+TSc                       *
 * -------------------------------------------------------------------------- *
 * Input                                                                      *
 * - pZeiger: Dateizeiger.                                                    *
 * Process                                                                    *
 * + Variablen                                                                *
 * - ulgDatei: Angestrebte Zielgroesze fuer die Datei.                        *
 * - intAnzahl: Eingegebenen Anzahl von Einheiten, die geschrieben werden     *
 *   sollen.                                                                  *
 * - intEinheit: Ausgewaehlte Groesze der Einheit.                            *
 * - intI: Zaehler.                                                           *
 * - intL: Laenge.                                                            *
 * - intP: Position.                                                          *
 * - strAnzahl: Inhalt des Editfeldes Anzahl,                                 *
 *   welche in eine Zahl umgewandelt werden soll.                             *
 * - strEinheit: Inhalt des Editfeldes Einheit,                               *
 *   welche in eine Zahl umgewandelt werden soll.                             *
 * Output                                                                     *
 * - ulgDatei.                                                                *
 ******************************************************************************/
unsigned long filesize(void * pZeiger)
{
 …

Einrückung mit Tabulatoren

Sehr lange Zeit haben wir für die Einrückung pro Ebene ein Leerzeichen verwendent. Hauptsächlich auf Grund von Limitierungen der Zeichen pro Zeile. Jetzt haben wir es bereits 2019 und die Technik hat sich massiv weiterentwickelt. Effizienter ist es mit Tabulatoren einzurücken, weil:

  • Die Breite eines Tabulators kann in allen Entwicklungsumgebungen eingestellt werden (jeder hat einen anderen Geschmack).
  • Wenn der Code (aus welchen Gründen auch immer) wieder auf Leerzeichen-Einrückung umgewandelt werden muss, kann man diesen sehr leicht wieder auf ein einzelnes Leerzeichen zurückführen. Dies entspricht dann auch wieder unseren klassischen Einrückung.
  • Klare Trennung von Tabulator = Einrückung und Leerzeichen = Leerzeichen in einem String.
  • Die meisten Editoren nehmen Tabulatoren ohne weitere Einstellungen an. Diese machen sich sogar oft die Tabulatoren zu nutze und rücken automatisch ein wenn man einen neuen "Block" {} schreibt.
Edit v1.400 from 2005-03-29 to 2019-07-08 by HSc+SBa+TSc

Benennung

Der Name von Konstanten, Variablen und Objekten hat die Aufgabe diese zu beschreiben. Es sollte aber nicht die maximale Größe von 240 Zeichen pro Name ausgenutzt werden. Der Seitenrand eines Blattes Papier im Format A4 und bei einer Schriftgröße von 10, ist bei 80 Zeichen pro Zeile auch ausgereizt. Es sollte nicht mehr als ein Name pro Zeile stehen. Ein Kompromiss ist irgendwo zwischen 8 und 16 Zeichen pro Name zu finden.

Die ungarische Notation, welche auch von namhaften Herstellern verwendet wird, wurde mit Einführung der objektorientierten Programmierung, durch Reddick für Visual Basic überarbeitet. An diese angelehnt sind die Vorgaben, die in der Firma "H&S<-EDV" für diese gelten.

Die grundsätzliche Form der ungarischen Notation ist: PLACEHOLDER_NOTATION_LNKLST
An Hand der Präfixe, Typbezeichnung und eventuellem Suffix von Konstanten, Variablen und Objekten, erkennt man, ohne nach der Deklaration der selbigen suchen zu müssen, von welchen Datentyp diese sein sollte und wofür diese eingesetzt wird.


Variablen

Zuerst kommt der Präfix (optional) mit dem entsprechnden Typkürzel. Der Basisname der Variable wird englisch geschrieben, da Englisch die Weltsprache ist und heutzutage viele Programmierer in Teams aus verschiedenen Ländern stammen. Der Basisname beginnt immer mit einen großen Anfangsbuchstaben, ebenso der Suffix, welcher direkt an den Basisnamen angefügt wird. Vom Gesamtbild her sind die Variablennamen nach dem "lower camel case"-Prinzip (halloSchoenesWetterHeute) aus Java verkettet.

Zum Bsp. die Variable für die Anzahl der € als Ganzzahl ohne Vorzeichen (unsigned int) könnte uiEuroCount mit
  • der Typ uiEuroCount für unsigned int
  • dem Name der Variable uiEuroCount für € und
  • dem Suffix uiEuroCount für die Anzahl.

Präfixe

TODO

Typbezeichnungen

TODO

Beschreibung der primitiven Datentypen.
Typ Kürzel Länge Wertebereich Beispiel
Primitive Typen (allgemein)
bool b Platformabhängig, d.h. die Länge hängt von der CPU−Architektur ab. 0 = false (falsch)
1 = true (wahr)
bool bStatus = false;
auto bSchalter = true;
char8_t c8 genau 8 Bit, für UTF-8 (ab 2020) -127…128 char8_t c8Symbol = u8'A';
auto c8Zeichen = u8'?';
char16_t c16 genau 16 Bit, für UTF-16 -32.768…32.767 char16_t c16Symbol = u'A';
auto c16Zeichen = u'?';
char32_t c32 genau 32 Bit, für UTF-32 -2.147.483.648…2.147.483.647 char32_t c32Symbol = U'A';
auto c32Zeichen = U'?';
char c
ac
genau 8 Bit Signed: -127…128
Unsigned: 0…255
'1', 'a', '~'
char cZeichen = 'A';
auto acSymbol = '?';
wchar_t c
wc
16 Bit (Windows) oder 32 Bit Signed: -32.768…32767
Unsigned: 0…65.535
L'1', L'a', L'~'
wchar_t cZeichen = L'A';
auto wcSymbol = L'?';
Primitive Ganzzahlen
short
short int
signed short
signed short int
unsigned short
unsigned short int
s mindestens 16 Bit Signed: -32.768…32.767
Unsigned: 0…65.535
short sZahl = ((short)13);
auto sNummer = static_cast<unsigned short>(42u);
int
signed
signed int
unsigned
unsigned int
i mindestens 16 Bit, generell 32 Bit Signed: -2.147.483.648…2.147.483.647
Unsigned: 0…4.294.967.295
unsigned int uiGroesze = 23u;
auto iZahl = 42;
long
long int
signed long
signed long int
unsigned long
unsigned long int
l mindestens 32 Bit Signed: -2.147.483.648…2.147.483.647
Unsigned: 0…4.294.967.295
unsigned long ulAnzahl = 3466ul;
auto lNummer = 32539l;
long long
long long int
signed long long
signed long long int
unsigned long long
unsigned long long int
ll mindestens 64 Bit Signed: -9.223.372.036.854.775.808…9.223.372.036.854.775.807
Unsigned: 18.446.744.073.709.551.615
unsigned long long ullGefunden = 63ull;
auto llAnzahl = 32434635ll;
Primitive Gleitkommazahlen
float f genau 32 Bit ±1,18×10−38…±3,4×1038, (circa 7 Dezimalziffern) +0, −0, +∞, −∞ und verschiedene Bitmuster für NaN's float fPi = 3.14159265359f;
auto fEuler = 2.7182818284f; ?
double d genau 64 Bit ±2,23×10−308…±1.80×10308, (circa 16 Dezimalziffern) +0, −0, +∞, −∞ und verschiedene Bitmuster für NaN's double dPi = 3.14159265359;
auto dEuler = 2.7182818284; ?
long double ld Compiler- und Plattformabhängig, meistens 80 Bit auf x86/64.
Auf Windows (64Bit) identisch zu double (getestet)
±3,65×10−4951…±1,18×104932, (circa 18 Dezimalziffern) +0, −0, +∞, −∞ und verschiedene Bitmuster für NaN's long double ldPi = 3.14159265359l;
auto ldEuler = 2.7182818284l; ?
 

Suffixe

TODO