Aussagekräftige Namen

Das Verhältnis zwischen Code-Lesen und Code-Schreiben entspricht mindestens 10:1. Es kann sehr viel Zeit beim Lesen und somit auch beim Schreiben eingespart werden, wenn der Code leicht lesbar ist.

• Zweckbeschreibende Namen wählen
  Statt
    int d; // abgelaufene Zeit in Tagen
  besser
    int elapsedTimeInDays;
  verwenden.


• Fehlinformation vermeiden
  
  • Der Buchstabe klein L ("l") hat in vielen Editoren eine große Ähnlichkeit mit der Ziffer "1".
  • Namen, die auf den ersten Blick gleich lauten.


• Unterschiede deutlich machen
  Unterschiedliche Dinge deutlich unterschiedlich benennen.
  Was ist der Unterschied zwischen account und accountData?


• Aussprechbare Namen verwenden
  Negativbeispiel: genymdhms für generationDate/year/month/day/hour/minute/second


• Suchbare Namen verwenden
  Die Länge eines Namens sollte der Größe seines Geltungsbereiches entsprechen.


• Codierungen vermeiden
  
  • Ungarische Notation - Unnötig, erschwert Änderung vom Typ
  • Member-Präfixe
    public class Part {
  private String m_dsc;
}
m_ ... Member-Präfix


• Interfaces und Implementierungen
  Oft wird dem Interface ein I vorangestellt. Besser die Implementierung codieren, z.B. durch Anhängen von Imp.


• Mentale Mappings vermeiden
  Man sollte einen Namen nicht mental in einen anderen Namen übersetzen müssen. Die Klarheit hat absoluten Vorrang.


• Klassennamen
  Sollte aus einem Substantiv oder substantivischen Ausdruck bestehen. Wörter wie Manager, Processor, Data oder Info sollten vermieden werden.


• Methodennamen
  Sollten aus einem Verb oder einem Ausdruck mit einem Verb bestehen.
  Wenn Konstruktoren überladen werden, sollte man statische Factory-Methoden mit Namen verwenden, die die Argumente beschreiben:
  Complex fulcrumPoint = Complex.FromRealNumber(23.0);
  ist im Allgemeinen besser als
  Complex fulcrumPoint = new Complex(23.0);


• Humorige Namen vermeiden


• Ein Wort pro Konzept
  Es ist verwirrend, wenn fetch, retrieve und get als Namen für gleichwertige Methoden verschiedener Klassen verwendet werden.


• Keine Wortspiele
  Man soll für zwei Zwecke nicht dasselbe Wort verwenden.


• Namen der Lösungsdomäne verwenden
  Man soll Fachbegriffe der Informatik, Algorithmennamen, Pattern-Namen, mathematische Begriffe usw. verwenden.


• Namen der Problemdomäne verwenden
  Wenn es keinen Termini aus der Informatik für eine Aufgabe gibt, soll man die Namen aus der Problemdomäne entlehnen.


• Bedeutungsvollen Kontext hinzufügen
  Für zusammengehörige Variablen eine Klasse verwenden, alternativ mit einem gemeinsamen Präfix versehen.
  addrStreet, addrState
  state alleine wäre nicht aussagekräftig.


• Keinen überflüssigen Kontext hinzufügen
  Nicht jedem Klassennamen einen Präfix der Problemdomäne hinzufügen.
  Wenn die Anwendung "Gas Station Deluxe" heißt, nicht den Klassen GSD voranstellen.