- In der modernen Softwareentwicklungskultur werden Projekt- und Bibliotheksnamen zunehmend mit beliebigen Wörtern gefüllt, die nichts mit ihrer Funktion zu tun haben
- Früher beschrieben Namen wie grep, awk, sed, FORTRAN, COBOL ihre Funktion oder ihren Zweck direkt, heute wimmelt es dagegen von bedeutungslosen Bezeichnungen
- Dieser Trend hat sich mit der Ausbreitung von GitHub- und Startup-Kultur beschleunigt, sodass die Verbindung zwischen Name und Funktion vollständig abgerissen ist
- Die Verständniskosten und die kognitive Belastung steigen, und Entwickler wiederholen unnötige Recherchen, um die Rolle einzelner Tools zu verstehen
- Der Text fordert die Wiederherstellung klarer, funktionsorientierter Benennungsregeln und betont, dass bei technischen Werkzeugen Klarheit und Professionalität vor Branding stehen sollten
Wandel der Benennungspraxis in der Software
- Richard Stallman sprach 2022 auf der EmacsConf über die Bedeutung von „leicht zu merkenden Namen“ und betonte, dass Paketnamen erkennen lassen sollten, was sie tun
- Das Emacs-Ökosystem hat traditionell funktionsbasierte Namen wie dired (Verzeichnis-Editor) und eshell (Emacs-Shell) beibehalten
- Moderne Entwickler neigen jedoch dazu, ihren Tools Namen wie zufällige Substantive, mythologische Wesen oder fiktive Figuren zu geben
- In anderen technischen Disziplinen würde ein solches Verhalten als Mangel an Professionalität gelten
Das Problem bedeutungsloser Namen
- Beispielhaft lassen Namen wie „Viper“, „Cobra“, „Melody“, „Casbin“ oder „Asynq“ keinerlei Rückschluss auf ihre Funktion zu
- Der Autor erwähnt, dass er sogar suchen musste, um die Infrastruktur-Erklärung eines Freundes zu verstehen
- In anderen Ingenieurdisziplinen beschreiben Namen Struktur oder Funktion
- Beispiele: Golden Gate Bridge, Hoover Dam, I-beam, butterfly valve – Form oder Rolle ist direkt erkennbar
- In der Chemie sorgt die IUPAC-Nomenklatur dafür, dass eine Bezeichnung genau ein Objekt meint
- Beispiel: 2,2,4-trimethylpentane bezeichnet genau ein Molekül; niemand würde es willkürlich „Steve“ nennen
Frühere Benennungsregeln und der heutige Bruch
- In den 1980er-Jahren dominierten funktionsbasierte Abkürzungen wie grep, awk, sed, cat, diff
- Auch Programmiersprachen wie FORTRAN, COBOL, BASIC, SQL, Lisp spiegelten ihren Zweck im Namen wider
- Seit den 2010er-Jahren begann die Ausbreitung bedeutungsloser Namen
- Manche Namen wie MongoDB hatten noch einen funktionalen oder etymologischen Bezug, doch mit GitHub- und Startup-Kultur nahm die Zahl inhaltsleerer Bezeichnungen stark zu
- Als Ursache wird die Tendenz genannt, markenorientierte Erfolgsgeschichten wie Google nachzuahmen
Kognitive Kosten und sinkende Entwicklungseffizienz
- Namen wie libsodium machen es schwer, auf die Funktion zu schließen, und zwingen Entwickler immer wieder zu Kontextwechseln
- Schon die Frage „Warum sodium?“ kostet unnötig Zeit
- Je mehr Projektabhängigkeiten es gibt, desto stärker summiert sich diese kognitive Steuer (cognitive tax)
- Das führt zu sinkender Produktivität bei Entwicklern
- Der Autor kritisiert, dass beim Verarbeiten von Sätzen wie „Viper, Cobra, Melody …“ geistige Ressourcen für die Entschlüsselung bedeutungsloser Tokens verschwendet werden
Häufige Gegenargumente und ihre Widerlegung
- „Leicht zu merkende Namen sind fürs Marketing vorteilhaft“ → Tools für Entwickler sind keine Konsumprodukte, funktionale Klarheit ist wichtiger
- „Beschreibende Namen sind langweilig“ → Langeweile ist als Preis für Klarheit akzeptabel; chirurgische Instrumente sind auch langweilig, aber präzise
- „Das ist doch nur zum Spaß“ → Alle Nutzer zahlen den Preis dieses ‚Spaßes‘, was in der gesamten Branche zu Zeitverschwendung führt
- „Die guten Namen sind schon vergeben“ → Namespaces, Präfixe und Komposita können das Problem lösen; mindestens sollte ein Name mit der Funktion zusammenhängen
Wohin es nun gehen sollte
- Das Problem wird weniger als böse Absicht denn als Folge eines kulturellen Wandels erklärt
- Mit der Verschiebung des Programmierens von unternehmenszentrierten zu communityzentrierten Strukturen wurden soziale Normen geschwächt
- Die Lösung ist eine kulturelle Wiederherstellung von Benennungsregeln
- Statt Regulierung braucht es Verbesserungen durch wiedergewonnene Professionalität, Ausbildung und sozialen Druck
- Bibliotheksnamen sollten ihre Funktion widerspiegeln; wenn nötig, sind auch Komposita und längere Ausdrücke akzeptabel
- Beispiel: „http-request-validator“ ist viel klarer als „zephyr“
- Maskottchen und Name sollten getrennt werden
- PostgreSQL verwendet zum Beispiel das Elefanten-Maskottchen Slonik, während der eigentliche Name funktional bleibt
- Wenn es sich nicht um ein Konsumprodukt mit wichtiger Markenbildung handelt, sollten Klarheit und Professionalität Vorrang haben
- Bevor man den Namen einer Lieblings-Animefigur vergibt, sollte man sich fragen: „Würde ein Bauingenieur einem Brückensystem so einen Namen geben?“
- Schlussendlich müsse die Wildwuchs bedeutungsloser Bezeichnungen beendet und zu klarer fachlicher Sprache zurückgekehrt werden
- Klarheit ist keine Langeweile, sondern Respekt vor der Zeit und den kognitiven Ressourcen der Nutzer
Noch keine Kommentare.