Empfehlungen für gute ID- und Klassennamen

Artikel vom 21. Oktober 2008 (↻ 19. August 2021), exklusiv für Dr. Web. ISSN 1614-3124, #39. Schwerpunkt: Webentwicklung (RSS-Feed für alle Themen).

Dieser und viele andere Beiträge sind auch als hübsches, wohlerzogenes E-Book erhältlich: On Web Development. Wenn Sie sich speziell mit der Optimierung von CSS beschäftigen, ich habe einige Grundlagen in einem kleinen Buch zusammengetragen: CSS Optimization Basics.

ID- und Klassennamen haben nicht unwesentlichen Einfluss auf die Wartbarkeit von HTML-Dokumenten, und entsprechend wichtig ist, geeignete Namen zu gebrauchen. Zusammenfassend gilt, IDs und Klassen wenn möglich zu vermeiden, ansonsten funktionale, im Zweifelsfall generische Namen einzusetzen, und dabei auf »verständliche Knappheit« zu achten.

Im Folgenden wird sich IDs und Klassen in ihrer Funktion als Stylesheet-Selektoren angenommen, denn gemäß HTML-Spezifikation haben diese mehrere Rollen; so können IDs beispiels- und bekanntlicherweise auch als Linkziel sowie als Elementreferenz für Scripting dienen.

Grundregeln für gute ID- und Klassennamen

Die Problematik ist alt, die in priorisierter Reihenfolge zu beherzigenden Empfehlungen immer noch jung:

1. Beschränken Sie den Einsatz von IDs und Klassen auf ein Minimum. Diese Vorgehensweise ist am einfachsten zu merken und anzuwenden und stellt das geringste Wartbarkeitsproblem dar, wobei inhaltliche und funktionale Änderungen, die immer vorkommen können und gegen die man sich nicht schützen kann und muss, nicht mit rein optischen Änderungen verwechselt werden dürfen.

2. Verwenden Sie funktionsbezogene ID- und Klassennamen. Es ist für gewöhnlich die nächstbeste Wahl, Namen von der Funktion abzuleiten, wie beispielsweise nav, warnung oder fehler. Solche Namen haben nicht nur einen strukturellen Bezug, sondern können auch konzeptionellem Verständnis und Zusammenarbeit helfen. Funktionsverwandte Namen helfen der Wartbarkeit, und es bleibt im Hinterkopf, dass, sollte das jeweilige Element einmal seine Bedeutung ändern, substantiellere Änderungen wie neue Inhalte erforderlich sind.

3. Verwenden Sie neutrale ID- und Klassennamen. Wenn Sie keinen vernünftigen funktionellen Namen bestimmen können oder Sie eine ausschließlich darstellungsbezogene ID oder Klasse einführen (wie früher gerne bei alternierenden Tabellenzeilen), empfiehlt es sich, neutrale, generische Namen zu wählen, wie zum Beispiel alt, »alternativ«/»Alternative«, oder aux. Diese Option ist nicht unbedingt die beste hinsichtlich Verständnis und Kollaboration, aber eben auch seltener ein Wartungsproblem.

4. Allgemein: Bevorzugen Sie Namen, die so kurz wie möglich, aber so lang wie nötig sind. Versuchen Sie, auf den Punkt zu kommen (nav), aber opfern Sie nicht unbedingt Verständlichkeit (kontakt).

Das unempfehlenswerteste, was man machen kann, ist, präsentationsbezogene Namen zu verwenden, wie die unseligen rechts, lila, 1024 &c., inklusive clearfix. Solche Namen sind um jeden Preis zu vermeiden, da sie letztlich alle Vorteile von CSS rauben, und Sie bei Darstellungsänderungen also gezwungen wären, das HTML anzupassen.

Noch bessere ID- und Klassennamen

Es sind im Zusammenhang mit ID- und Klassennamen mindestens zwei »Boni« zu nennen, die in bestimmten Situationen wertvoll sind, zum einen »Pseudo-Namensräume«, zum anderen »Chamäleonsemantik«:

1. »Pseudo-Namensräume« sind Präfixes vor IDs und Klassen, die primär dazu beitragen können, Code in kollaborativer oder fremder Umgebung zu »schützen« (à la produktname-*). Auch wenn diese Pseudo-Namensräume auch dem konzeptionellem Verständnis dienen können, ist die Idee dahinter, die Wahrscheinlichkeit von unerwünschten Nebeneffekten zu minimieren (wenn der gewünschte Name bereits vergeben sein könnte oder mehr als einmal vergeben werden soll) und dadurch mehr Freiheit zu gewährleisten. Das Thema verdient insgesamt jedoch separate Behandlung, unabhängig von seiner Relevanz auch für Mikroformate.

2. »Chamäleonsemantik« bezieht sich auf Namen, die ihre Bedeutung ändern können, wie zum Beispiel spalte-1 und spalte-2. Üblicherweise findet man sie auf mehrspaltigen Seiten vor, und dort in der Bedeutung von »Spalte 1« und »Spalte 2«, weswegen man einen Präsentationsbezug wittern mag. Eine mögliche Layoutänderung auf ein einspaltiges Design muss aber dennoch keine HTML-Änderung bedeuten, und zwar dank besagten Chamäleoneffekts: spalte-1 und spalte-2 könnten durchaus als »Spalte, Teil 1« und »Spalte, Teil 2« verstanden werden.

Nachtrag (19. August 2021)

In seinem ausgezeichneten Buch A Philosophy of Software Design schreibt John Ousterhout über ungenaue Namen als Warnsignal: »If a variable or method name is broad enough to refer to many different things, then it doesn’t convey much information to the developer and the underlying entity is more likely to be misused.«

Sie können dies auch auf neutrale und generische ID- und Klassennamen anwenden. Das bedeutet, dass Sie deren Einsatz abwägen müssen: Generische Namen eignen sich besser in kleinen als in großen Projekten.

Über mich

Ich bin Jens (lang: Jens Oliver Meiert), und ich bin ein Frontend-Engineering-Leiter und technischer Autor/Verleger. Ich habe als technischer Leiter für Firmen wie Google und als Engineering Manager für Firmen wie Miro gearbeitet, bin Mitwirkender an verschiedenen Webstandards und schreibe und prüfe Fachbücher für O’Reilly und Frontend Dogma.

Ich experimentiere gerne, nicht nur in der Webentwicklung (und im Engineering Management), sondern auch in anderen Bereichen wie der Philosophie. Hier auf meiert.com teile ich einige meiner Erfahrungen und Ansichten. (Bitte sei kritisch, interpretiere wohlwollend und gib Feedback.)