Regeln der Namensgebung

Die Namenswahl (von Programmdateien, Variablen, Funktionen, usw.) ist eines der wichtigsten Elemente, die den Quellcode verständlicher macht. Die Weise, worauf man einen Variablennamen schreibt, kann uns unmittelbar informieren, was dieses Element repräsentiert, wie z. B. ob eine Variable, Funktion, Konstant usw. ist, ohne die Registrierung dieses Elementes suchen zu müssen. Ferner müssen die Namen irgendeinen Sinn haben und dem Entwickler die Möglichkeit geben, den Quellcode leichter zu begreifen und zu lesen. Ein Name, der anmutig ist, oder leicht zu tippen ist, kann später bei jemandem Probleme hervorrufen, der den Quellcode zu verstehen. Der Quellcode wird mehrmals gelesen, aber nur einmal geschrieben. Aus diesem Grund spielt die Namenskonventionen eine entscheidende Rolle und der Variablenname muss die Variable, die er repräsentiert, vollends und genau beschreiben ([1],[2], [3]).

Die Namenskonventionen sind ziemlich willkürlich, und aus diesem Grund sind die Konventionen, die weiter unten aufgeführt werden, eher Empfehlungen oder Konventionen, die von einem großen Entwicklerteil adoptiert worden sind, und keine Regeln.

Was da von Bedeutung ist, ist die konsequente Einhaltung der etwaigen Konventionen, die gewählt worden sind, oder die ursprünglichen Schöpfer des Quellcodes gebraucht [3].

Generalnamenskonventionen ([3],[1],[4],[5],[6])

  • Eine wirksame Technik für die Auffindung repräsentativer Namen ist die Erklärung mit Worten, was die Variable repräsentiert.

  • Die Namen, die man wählt, müssen repräsentativ sein, so dass der Quellcode sofort verständlich ist. Man darf keine Abkürzungen gebrauchen, die denjenigen unklar oder unbekannt sind, die den Quellcode zum ersten Mal lesen. Ferner darf man keine Abkürzungen durch das Streichen von Buchstaben innerhalb der Wörter gebrauchen. Weiter unten folgen einige "gute" und "schlechte" Variablennamen.

int price_count_reader; // No abbreviation. int num_errors; // "num" is a widespread convention. int num_dns_connections; // Most people know what "DNS" stands for. int n; // Meaningless. int nerr; // Ambiguous abbreviation. int n_comp_conns; // Ambiguous abbreviation. int wgc_connections; // Only your group knows what this stands for. int pc_reader; // Lots of things can be abbreviated "pc". int cstmr_id; // Deletes internal letters. int temp; // Is it temperature? Is it temporary?

  • Die Variablenlänge muss ihre Reichweite widerspiegeln. Eine Lokal-Variable hat eine geringe Reichweite, folglich braucht auch der Name nicht so beschreibend zu sein. Im Gegenteil muss eine Global-Variable von großer Reichweite einen repräsentativen und beschreibenden Namen haben, damit sie leicht zu unterscheiden ist.

  • Die Abkürzungen und Kurzformen müssen großgeschrieben werden, wenn sie als Variablennamen gebraucht werden.

  • In der Wiederholungsschleifen müssen Namen mit bestimmter Bedeutung gebraucht werden, wie in den weiter unten stehenden Beispielen:

for (window_index = 0; window_index <= window_count; ++window_index) { ... }

Namenskonventionen

Die weiter oben Einheit erwähnt einige von den verbreitesten Regeln, die bei den Namenskonventionen gebraucht werden. In erster Linie werden Regeln für die C++ umfasst, aber sie können auch in die übrigen Programmsprachen verallgemeinert werden.

Programmdateien

  • Für die Programmdateien muss man einen Namen aussuchen, der den Inhalt der Datei widerspiegelt.
  • Die Dateinamen müssen alle (in Klein-buchstaben sein) kleingeschrieben werden und sie können den Unterstrich (_) oder den Oberstrich (-) umfassen.
  • Die Programmdateien von C++ müssen in .cpp und von C in .c, aber die Header-Dateien in .h enden.
my_useful_class.cpp my-useful-class.cpp myusefulclass.h myusefulclass_test.h

Defines & Macros

  • Die Prozessordeklarationen und die Macros müssen in Großbuchstaben sein. Ferner müssen die Prozessordeklarationen für die Programmdateien mit einem Unterstrich (_) enden.
#ifndef MODULE_NAME_FILE_NAME_HPP_ #define MODULE_NAME_FILE_NAME_HPP_ // the code #endif // MODULE_NAME_FILE_NAME_HPP_

Variable

  • Die Variablennamen (engl. Variables) sind alle in kleingeschrieben, mit Strichen zwischen den Wörtern.
  • Für die globalen Variablen gibt es keine besonderen Ansprüche, da ihr Gebrauch selten ist, aber wenn auf jeden Fall manche gebraucht wird, wäre es gut, differenziert zu werden, indem man ein g_ oder irgendein anderes Merkmal voranstellt, das sie von den Lokal-Variablen differenziert.
string table_name; // OK - uses underscore. string tableName; // Bad - mixed case. int g_a_global_variable;

Funktionen

  • Die Funktionen (Engl. functions) müssen camelCased1 sein und die Variablen müssen kleingeschrieben sein, mit Unterstrich zwischen den Wörtern.
  • Der Rückgabetyp jeder Funktion muss in eine andere Zeile gesetzt werden.
  • Man muss ein Verb als Namen auswählen, das die Funktionstätigkeit reflektiert. Man sollte Namen auswählen/es sollten Namen gewählt werden, die die Problemelemente reflektieren und nicht die Problemlösung.
int applyExample (int example_arg); void checkForErrors();

Typennamen

  • Die Typennamen (Engl. Type names) sind CamelCased. Das heißt, dass sie mit einem Großbuchstaben anfangen und auch jedes neue Wort mit einem Großbuchstaben anfangen muss, ohne dass ein Unterstrich (_) davor steht.
// classes and structs class UrlTable { ... class UrlTableTester { ... struct UrlTableProperties { string name; int num_entries; } // typedefs typedef hash_map<UrlTableProperties *, string> PropertiesMap; // enums enum UrlTableErrors { ...

Strukturen

  • Die Glieder/Teile einer Struktur müssen als normale Lokalvariablen aufgeschrieben werden.
struct UrlTableProperties { string name; int num_entries; }

Enum

  • Die Glieder der Aufzählungen (Engl. enumerations) müssen großgeschrieben sein, mit Strichen zwischen den Wörtern. Mit den Großbuchstaben werden diese Variablen in einem Programm unterschieden und sie werden nicht mit den einfachen Variablen verwechselt.
enum Color { COLOR_RED, COLOR_GREEN, COLOR_BLUE };

Klassen (1)

  • Die Teile einer Klasse müssen folgendermaßen eingeordnet werden: öffentlich, geschützt (Engl. public, protected) und privat (Engl. private). So dass die Entwickler, die die Klasse einfach gebrauchen wollen, nicht auch die privaten Klassenglieder lesen müssen.

  • Die privaten Klassenglieder sind genau so wie die einfachen Variablen, nur dass sie mit einem Unterstrich (_) enden müssen. Wenn man die Breite mit einem Unterstrich markiert, macht man die Klassenvariablen-trennung der gebrauchten Lokal-Variablen leichter.

class ExampleClass { public: ... protected: ... private: int example_name_; }

Klassen (2)

  • Eine Klasse muss in einer Header-Datei (Engl. header file) deklariert und in einer Quelldatei (Engl. source file) definiert werden, deren Dateinamen so wie die Klassennamen dieselben sind, so dass die Auffindung der entsprechenden Dateien leichter ist. Die Header-Datei muss eine Schnittstelle deklarieren und die Quelldatei muss sie realisieren.
  • Die Dateien, die die Klassen realisieren, haben die Endung .hpp .
  • Die Abfragefunktion (Engl. aceessors,mutators) oder Funktionen get und set) müssen mit dem Variablennamen gleich sein, auf den sie sich beziehen
class ExampleClass { public: ... int getNumEntries() const { return num_entries_; } void setNumEntries (int num_entries) { num_entries_ = num_entries; } protected: ... private: int num_entries_; int example_name_; }

Unterordner

In weiter unten wird die typische Ordnerstruktur eines typischen Programms präsentiert. Gleichfalls auch da sind diese Ordner die meistens benutzten Ordner.

Υπο-φάκελος Περιεχόμενα
include Die Header-Dateien.
include/impl/ Die die Klassen realisierenden Dateien.
src Die Quelldateien, die für die Programmkompilierung nötig sind.
build Die ausführbaren Programmdateien.
doc Die ausführbaren Programmdateien.
1. CamelCase ist die Praxis der zusammengesetzten Wörter- oder Phrasen/Satzschriften, so dass jedes Wort oder jede Abkürzung mit einem Großbuchstaben beginnt. Das ermöglicht die Verringerung der Größe der Sätze, da kein Abstand oder irgendein anderer spezifischer Charakter zwischen den Wörtern gebraucht werden (z.B. "_" [7],[8]) ↩

1David H. Leserman, FX-ALPHA C and C++ Coding Conventions,
2Taligent Inc, Taligent Documentation,
3Google, Google C++ Style Guide,
4Geotechnical Software Services, C++ Programming Style Guidelines,
5Sutter, Herb and Alexandrescu, Andrei, C++ coding standards: 101 rules, guidelines, and best practices, Pearson Education, 2004.
6Kernighan, B.W. and Ritchie, D.M., The C Programming Language, Prentice Hall, 1988.
7Wikipedia, CamelCase --- {W}ikipedia{,} The Free Encyclopedia,
8YoLinux.com, C++ Coding Practices, Style, Standards and document generation (dOxygen),





results matching ""

    No results matching ""