Lesbarkeit

29. Oktober 2003, Letzte Änderung: 24. August 2009

Eine Notation kann zu kurz sein. Wenn der Name einer selten verwendeten Funktion nur aus einem Buchstaben besteht (»t«), dann muss man sie womöglich die wenigen Male, die man sie sieht, nachschlagen, wenn man alle Buchstaben nicht auswendig komplett überblickt. Ein komplettes Wort (»translate«) ist da die bessere Lösung.

Eine Notation kann auch zu lang sein. Wenn ein Schlüsselwort, das man sehr oft verwendet, 20 Zeichen lang ist (»shapeoutlinedata«), dann sollte es womöglich besser abgekürzt werden (»d«). Diese Beispiele habe ich aus SVG (das die richtigen Bezeichnungen gewählt hat) entnommen, aber man kann ähnliche Fälle in den meisten Sprachen finden.

Anmerkung des Übersetzers:

Der Autor meint hier folgendes: Je kürzer ein Bezeichner oder ein Befehl ist, desto schneller lässt er sich tippen. Andererseits geraten nichtssagende, knappe Abkürzungen schneller in Vergessenheit als komplette Wörter, die womöglich genau das bezeichnen, was sie bewirken. Daraus lässt sich der Schluss ziehen, dass häufig verwendete Bezeichner möglichst kurz und selten verwendete Bezeichner möglichst aussagekräftig und somit oftmals auch lang gewählt werden sollten. An den Befehlen aus der Unix-Welt (»cd«, »ls«, »procmail«, »troff«, »sort«, »tzselect«) lässt sich das gut nachvollziehen.

Bedauerlicherweise stellen sich die besten Vermutungen als falsch heraus. Die Designer von XML dachten, es wäre hilfreich, ein Element mit dem vollen Elementnamen zu öffnen und zu schließen (<heading>...</heading>), und für die Verwendung, die sie voraussahen, war das in der Tat vollkommen angemessen: in langen Texten mit wenig Markup ist die geringe Menge an Redundanz, die hinzukommt, gegenüber der Möglichkeit, zu sehen, welches Element geschlossen wird, zu vernachlässigen [XMLgoals]. Sie dachten, eine kürzere Form (etwa </> oder <>) zu erlauben, würde die Komplexität der Sprache erhöhen. Heute wird XML allerdings häufiger für Daten benutzt, deren Markup den eingeschlossene Inhalt übersteigt, und die vielen Start-Tags, die direkt End-Tags des gleichen Elementtyps folgen, verstecken die wesentliche Information durch ihre Redundanz. XML ist dadurch nicht kaputt, aber im Nachhinein betrachtet, hätte es so gestaltet werden können, dass dessen Verwendung nicht mit solchen Problemen verbunden ist.

Natürlich kann man immer eine andere Technik als XML verwenden. Und wenn die Lesbarkeit des Quelltextes wichtig ist, dann sollte man das vielleicht auch. Aber das bringt vielleicht Kosten mit sich: Man wird sich dann über einige Dinge Gedanken machen müssen, die XML von sich aus mit sich bringt (wie man Unicode-Zeichen umschreibt, wie man die Eindeutigkeit der Syntax sicherstellt, welche Begrenzer man für verschachtelte Strukturen verwendet, wie man Leerraum analysiert und vieles mehr).

Eine Möglichkeit, beides zu verwenden, sowohl XML als auch ein lesbares Format, ist die Verwendung eines Konverters. Für MathML beispielsweise gibt es mehrere Tools, die es erlauben, Mathematik in einer gewohnten Notation zu schreiben. Sobald es solche Tools gibt, ist die Lesbarkeit von Quelltexten weniger wichtig. Nicht allerdings unwichtig, siehe Langlebigkeit.

CSS hat seine eigene Syntax, denn Lesbarkeit ist sehr wichtig für eine Sprache, die bei nahezu genauso vielen Menschen verwendet wird wie HTML selbst. Es hätte auf SGML basieren können, und es gibt in der Tat einige Vorschläge für eine SGML-basierte Syntax (siehe [Lie99]), und es existiert auch noch der US-Militär-Standard ([FOSI], aber es wurde niemals bezweifelt, dass die heutige CSS-Syntax besser ist. (XML gab es zu dieser Zeit nicht, aber es hätte auch nicht weitergeholfen, weil es wortreicher als SGML ist und weniger Zeichen und Zeichensetzung erlaubt.)

Viele andere Sprachen wählen eine Mischung aus XML und einer anderen Syntax. XML selbst verwendet spitze Klammern als Begrenzer, alles andere muss mit Schlüsselwörtern erledigt werden. Menschen fühlen sich für gewöhnlich wohler, wenn andere Zeichen, zum Beispiel der Doppelpunkt (:), das Semikolon (;), geschweifte Klammern { } und runde Klammern ( ) ebenfalls eine Bedeutung haben. SMIL zum Beispiel drückt Zeit und Zeitintervalle mit einer Notation wie 3:25.5 und nicht <time><min>3</min><sec>25.5</sec></time> aus. Ebenso nutzt SVG eine kompakte Notation für Pfade, die wesentlich lesbarer ist als alles, was mit XML-Tags ausgedrückt werden könnte. Aber sowohl SMIL als auch SVG verwenden XML für die Teile, wo Wortfülle weniger das Problem ist, so wird die Arbeit des Entwicklers der Spezifikation leichter gemacht, ohne dass Probleme mit der Lesbarkeit auftreten.

Und es gibt Sprachen, bei denen Lesbarkeit im Vergleich zur Effizienz weniger wichtig ist. PNG ist ein Beispiel dafür. Es ist ein Binärformat.

Siehe auch

[FOSI]: . [Where is this thing?]
[Lie99]: Lie, Håkon Wium; Bos, Bert. Historical style sheet proposals. 1997-1999. W3C. URL: http://www.w3.org/Style/History
[XMLgoals]: Tim Bray; Jean Paoli; C. M. Sperberg-McQueen (eds). Extensible Markup Language (XML) 1.0. 10 Feb 1998. W3C Recommendation. Section 1.1 URL: http://www.w3.org/TR/REC-xml#sec-origin-goals