Naming ist wichtig

Manchmal reicht ein einzelner Feldname, um zu zeigen, wie viel Architektur eigentlich in einer Namensentscheidung steckt. Ein aktueller Pull Request im LimeSurvey-Kernrepository liefert dafür ein besonders klares Beispiel.

Der Fall

Am 14. August 2026 wurde im LimeSurvey-Repository der Pull Request #5236 eingereicht: ein neues Feature, das Surveys um einen zusätzlichen, sprachunabhängigen Titel erweitert – gedacht als interne Bezeichnung zur Identifikation im Administrationsbereich, unabhängig vom öffentlich sichtbaren, lokalisierten Umfragetitel.

Technisch ist das ein sinnvolles Feature. Der bestehende Titel einer Survey (survey_languagesettings.surveyls_title) ist an eine Sprache gebunden und für interne Zwecke – etwa das Wiederfinden einer Umfrage in einer langen Liste – oft ungeeignet. Ein zweites, sprachneutrales Feld schließt eine echte Lücke.

Der PR führt dieses Feld unter dem Namen projecttitle ein – als Datenbankspalte, als API-Property, als Bezeichner, der sich durch Backend, Frontend und Schema zieht.

Genau hier liegt das Naming-Problem: In LimeSurvey existiert keine Entität “Project”. Es gibt keine Survey-zu-Project-Beziehung, kein project_id, kein Projektmodell irgendeiner Art. Das neue Feld beschreibt schlicht den internen Titel einer Survey – nicht den Titel eines Projekts, das es gar nicht gibt.

Ältere Feature Requests im LimeSurvey-Bugtracker beschreiben genau diese Anforderung bereits als “internal title” – etwa #18740 „Have internal title (for admin) different than public title", das später als Duplikat von #18873 geschlossen wurde. Ob das interne Ticket AT-2107 bzw. PR #5236 unmittelbar auf diese Requests zurückgeht, ist öffentlich nicht dokumentiert. Bemerkenswert ist trotzdem: Die fachliche Terminologie war bereits vorhanden, bevor der PR entstand. Irgendwo zwischen Anforderung und Implementierung ist daraus projecttitle geworden.

Auch das bestehende Datenmodell legt eine andere Benennung nahe: Der öffentliche Titel liegt als surveyls_title in survey_languagesettings und ist damit explizit sprachabhängig. Das neue Feld liegt dagegen direkt in surveys und ist sprachunabhängig. Ein Name wie internal_title würde genau diese bereits vorhandene Trennung benennen: lokalisierter Inhalt dort, interne Bezeichnung hier.

Der vorgeschlagene Alternativname: internal_title.

Warum das kein Bikeshedding ist

Man könnte das für eine rein kosmetische Debatte halten – Namensdiskussionen haben in der Softwareentwicklung keinen guten Ruf, gerade weil sie oft genau das sind: Geschmacksfragen ohne funktionalen Unterschied, klassisches Bikeshedding¹.

Hier liegt der Fall anders. Ein Feldname ist keine bloße Kennzeichnung, er ist ein Versprechen über die Domäne. Wer projecttitle liest, geht implizit von einem Projektbegriff aus – auch wenn keiner explizit dokumentiert ist. Namen wirken als Hypothesen über die Struktur des Systems, lange bevor irgendjemand eine formale Modellierung vornimmt. Entwickler, die später mit dem Feld arbeiten, werden unweigerlich fragen: Wo ist die Project-Entität, zu der das gehört? Gibt es eine Beziehung, die ich übersehen habe? Die Antwort – nein, es gibt keine – lässt sich nur durch Nachlesen im Code herausfinden, nicht durch den Namen selbst.

Besonders greifbar wird das Risiko, wenn man es zu Ende denkt: Sollte LimeSurvey irgendwann tatsächlich eine Projekt-Gruppierung für Surveys einführen – eine durchaus plausible Zukunft für ein wachsendes System –, kollidiert der bereits vergebene Name mit der dann echten Bedeutung. $survey->projecttitle wäre weiterhin der interne Survey-Titel, würde sich neben einer echten Project-Entität aber wie der Titel des übergeordneten Projekts lesen:

$survey->projecttitle;
$survey->project->title;

Zwei Ausdrücke, die nahezu dasselbe zu benennen scheinen, aber zwei völlig verschiedene Konzepte meinen.

Das ist der Kern des Problems: Ein Name legt nicht nur eine Bezeichnung fest, sondern reserviert implizit einen Begriffsraum. projecttitle verbraucht das Wort Project, obwohl das Domänenmodell überhaupt kein Project kennt. Wird der Begriffsraum falsch reserviert, entsteht keine falsche Zeile Code – sondern eine dauerhafte Quelle von Fehlannahmen, die sich mit jedem neuen Entwickler, jeder neuen Integration, jedem Plugin, das auf das Feld zugreift, wiederholt.

Die Ökonomie der Korrektur

Der eigentlich interessante Punkt ist weniger die Namensfrage selbst als der Zeitpunkt, zu dem sie gestellt wird.

Solange projecttitle nur Teil eines offenen Pull Requests ist, ist eine Umbenennung noch vergleichsweise billig: Datenbankspalte, Model, API-Schema und Frontend können gemeinsam angepasst werden, ohne einen bereits veröffentlichten Vertrag brechen zu müssen. Der entscheidende Unterschied ist dabei nicht “keine Kosten vs. hohe Kosten” – der PR zieht den Namen schließlich bereits durch etliche Komponenten. Der entscheidende Unterschied ist interne Änderung vs. externe Kompatibilitätskosten. Sobald das Feld gemerged, released und Teil von Datenbankschema und API ist, ändert sich die Rechnung fundamental: Mögliche Plugins und Integrationen, die bereits auf projecttitle zugreifen, Dokumentation, die den Namen zitiert, Migrationspfade, die sich nicht rückstandslos zurückrollen lassen. Jede dieser Abhängigkeiten macht eine spätere Korrektur teurer – nicht linear, sondern in etwa proportional zur Zahl der Systeme, die sich inzwischen auf den Namen verlassen.

Diese Asymmetrie – günstig vor dem Release, teuer danach – ist der eigentliche Grund, warum ein Kommentar zu einem Feldnamen mehr verdient als ein Schulterzucken. Es geht nicht darum, ob projecttitle “falsch” im moralischen Sinne ist. Es geht darum, an welcher Stelle der Kette – Commit, PR, Merge, Release, Schema, Plugins, öffentlicher Vertrag – ein Name aufhört, sich beinahe kostenlos korrigieren zu lassen.

Fazit

Ob der PR am Ende mit projecttitle oder internal_title gemerged wird, ändert an der eigentlichen Beobachtung nichts. Der Fall zeigt exemplarisch, was in jeder größeren Codebasis passiert: Namen werden unter Zeitdruck vergeben, an der Oberfläche wirken sie neutral, und erst im Rückblick – oder durch einen aufmerksamen Reviewer – wird sichtbar, welches Domänenmodell ein solcher Name eigentlich verspricht.

Der günstigste Zeitpunkt, einen Namen zu hinterfragen, ist nicht dann, wenn er stört. Es ist der Moment, bevor er Teil eines öffentlichen Vertrags wird.