Intuitive Namensgebung und Länge von Namen im (Java-)Code

Als Softwareentwickler stehen wir des Öfteren vor dem Problem, einen Namen für eine Klasse, eine Methode oder eine Variable zu finden. Bei dieser doch sehr alltäglichen Arbeit kann man aber schon viele Fehler begehen. Sind schlecht gewählte Bezeichnungen doch schnell irreführend und damit nicht gerade intuitiv verstehbar. Doch gerade bei der Softwareentwicklung ist Intuition und die adäquate Wahl eines „guten“ Namens wichtig. Schließlich „lebt“ eine solche Software meistens einige Jahre bis Jahrzehnte. Gerade im Enterprise-Umfeld muss eine Software auch nach fünf Jahren noch wartbar sein. Aber auch das private Heimprojekt sollte so gestaltet sein, dass man nach einem halben Jahr noch die Hauptfunktionen durch einfaches Lesen im Code herausfinden kann. Hier sind intuitive Namen das A und O!

Einer der bekanntesten Verfechter von intuitiver Benennung von Codebestandteilen ist unter anderem Robert C. Martin mit seinem Buch „Clean Code: A Handbook of Agile Software Craftsmanship„. Das Buch ist ebenso in einem Videoformat erhältlich, wobei sich direkt die zweite Episode mit der korrekten Bezeichnung von Funktionen und Klassen beschäftigt.

Doch schauen wir uns ein Beispiel an, im folgenden Codeschnippsel kann man sich ein sehr einfaches Beispiel anschauen:

public class Getraenk {
	private String name;
	private BigDecimal x;
}

Hier ist lediglich dem Autor klar, das die Variable „x“ ggf. den Preis des jeweiligen Getränks bezeichnen sollte. Oder vielleicht doch die Menge des Getränkevorrats in einem Automaten? Oder etwas ganz anderes… Wie auch immer, der Name „x“ ist in jedem Fall schlecht gewählt und selbst der Autor wird in drei Monaten nicht mehr wissen, was genau er damit meinte.

Idee: Ich ergänze den schlechten Variablennamen um einen Kommentar:

public class Getraenk {
	private String name;
	private BigDecimal x; // Preis des Getränks
}

Jetzt ist doch jedem klar worum es geht. Super! … Nein, leider nicht, den anstelle einen Kommentar zu nutzen, den ich im übrigen ja auch jeweils am Getter und Setter anbringen müsste, sollte ich die Variable doch gleich korrekt benennen: der Name sollte die Funktion bzw. den Inhalt widerspiegeln. Besser wäre also:

public class Getraenk {
	private String name;
	private BigDecimal preis;
}

Im Bereich der Variablen, Methoden, Klassen etc. kann man so viele Kommentare sparen und die Dinge einfach so benennen wie sie sind bzw. passend zum Inhalt den sie repräsentieren.

Doch wie lang sollten Namen sein? Ich kann ja auf Basis dieser Idee Methoden mit beliebig langen Namen versorgen, je nachdem wie genau ich es denn haben möchte. Was ist besser:

public void erzeugeListe();
public void erzeugeListeVonPersonen();
public void erzeugeListeVonBerechtigtenPersonen();

Irgendwie sieht das auch nicht sinnvoll aus. Hier kommt ein weiteres Konzept ins Spiel. Namen sollten zu ihrem Scope, sprich zu ihrem Umfeld, ihrem Kontext passen. Sprich Namen von zum Beispiel private-Methoden können eher etwas länger sein (sie werden nicht so häufig genutzt) und Namen von public-Methoden in Interfaces sollten eher kürzer sein (denn sie werden potentiell sehr häufig verwendet).

Daraus lassen sich folgende allgemeine Regeln ableiten:

Variablen Methoden Klassen
Großer Scope längere Namen kurze Namen je nach Fachlichkeit
Kleiner Scope kurze Namen längere Namen je nach Fachlichkeit

Mit Hilfe dieser Regeln ergeben sich sinnvollere Namenslängen. So werden häufig verwendete Methodennamen eher kurz gehalten, wohingegen versteckte Methodennamen in Klassen auch gerne etwas längere und damit beschreibendere Namen haben dürfen. Das ist in diesem Sinne natürlich kein Gesetzt, niemand muss sich daran halten. Es schafft aber eine gute Ausgangsbasis um intuitive und gute Namen zu vergeben. Man sollte sich immer der Funktion und dem Scope eines Codeblocks bewusst sein und dementsprechend auch dessen Namen wählen.

Tipp am Rande: Bleibt bei Namen in dem fachlichen Umfeld des Kunden/Auftraggebers und zieht dich bis in den Code durch. Es macht keinen Sinn ein erzwungenes Mapping zwischen „so nennt der Kunde es“ und „so heißt es im Code“ einzuführen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.