identifiers

Identifiers (Bezeichner)

Kurz: Die Namen, die man Variablen, Methoden, Klassen usw. im Code gibt — müssen bestimmten Regeln folgen (keine Leerzeichen, kein Start mit Ziffer, keine reservierten Schlüsselwörter).

Genauer: Jede Sprache hat eigene Regeln, was ein gültiger Identifier ist (meist: Buchstaben, Ziffern, Unterstrich, nicht mit Ziffer beginnend) und eigene Namenskonventionen, die zwar nicht erzwungen, aber Standard sind (z. B. camelCase für Variablen in Java/JavaScript, PascalCase für Klassennamen).

Im Detail

Die formalen Regeln sind meist minimal (kein Leerzeichen, kein Start mit Ziffer, keine reservierten Schlüsselwörter wie class oder if als Name), doch guter Code lebt von den ungeschriebenen Konventionen darüber hinaus: sprechende statt kryptischer Namen (kundenListe statt kl), Konsistenz innerhalb eines Projekts, und sprachspezifische Groß-/Kleinschreibungsstile:

int alter;              // camelCase - Variablen/Methoden in Java
class KundenVerwaltung { // PascalCase - Klassen in Java
}
final int MAX_VERSUCHE = 3; // SCREAMING_SNAKE_CASE - Konstanten

Manche Sprachen erzwingen Konventionen sogar auf Compiler-Ebene: in Go entscheidet die Groß-/Kleinschreibung des ersten Buchstabens über Sichtbarkeit (öffentlich vs. paketintern), in Python signalisiert ein führender Unterstrich per Konvention “privat”, ohne technisch erzwungen zu werden. Schlechte Identifier-Wahl ist einer der häufigsten Gründe, warum fremder (oder eigener, älterer) Code schwer verständlich ist — der Name sollte idealerweise schon erklären, wofür die Variable steht, ohne dass ein Kommentar nötig ist.

Reservierte Schlüsselwörter

Jede Sprache hat eine feste Liste reservierter Wörter, die NICHT als Identifier verwendet werden dürfen, weil sie bereits eine feste Bedeutung in der Sprachsyntax haben (if, for, class, return usw.). Versucht man trotzdem, eine Variable class zu nennen, bricht der Compiler mit einem Syntaxfehler ab. Manche Sprachen erlauben ein Escaping für Sonderfälle — in Kotlin etwa lässt sich ein Schlüsselwort mit Backticks als Identifier nutzen (`class`), was gelegentlich beim Interop mit Java-Bibliotheken nötig ist, die einen dort erlaubten, in Kotlin aber reservierten Namen verwenden.

Namenskonventionen im Sprachvergleich

Die konkreten Konventionen unterscheiden sich merklich zwischen Ökosystemen: Python und Ruby bevorzugen snake_case (kunden_liste) für Variablen und Funktionen, Java/JavaScript/C# camelCase (kundenListe), während Konstanten in fast allen C-artigen Sprachen traditionell SCREAMING_SNAKE_CASE erhalten. Diese Konventionen sind nicht willkürlich, sondern haben sich historisch in den jeweiligen Sprachcommunitys etabliert und werden heute meist durch automatisierte Linter (ESLint, Checkstyle, Pylint) durchgesetzt, damit ein Team nicht auf manuelle Code-Reviews für simple Stilfragen angewiesen ist.

Namensraum-Kollisionen vermeiden

Bei größeren Projekten mit vielen Entwicklern wird die Eindeutigkeit von Identifiers zum eigenen Problem: Zwei unabhängig entwickelte Bibliotheken könnten beide eine Klasse User definieren. Sprachen lösen das über Namensräume (Namespaces in C++/C#, Packages in Java, Module in Python/JavaScript) — der volle, eindeutige Identifier wird dann zu etwas wie com.firma.User oder auth.User, während im lokalen Code meist nur der kurze Name genutzt wird, sofern keine Mehrdeutigkeit besteht.

Siehe auch: Declaring Variables, Constants (final)