Fachlichen Code schreiben: Excusez-moi, do you sprechen Español?

Programmieren bedeutet nicht nur, technischen, sondern vor allem auch fachlichen Code zu schreiben. Doch in welcher natürlichen Sprache?

In Pocket speichern vorlesen Druckansicht 223 Kommentare lesen
Lesezeit: 6 Min.
Von
  • Golo Roden
Inhaltsverzeichnis

Zu programmieren bedeutet nicht nur, technischen Code, sondern vor allem auch fachlichen Code zu schreiben. Dabei stellt sich rasch die Frage, in welcher natürlichen Sprache Dinge benannt werden sollten. In der eigenen Muttersprache? Auf Englisch? Auf Esperanto? …?

In der Informatik gibt es die gängige Wendung, dass es tatsächlich nur zwei schwierige Probleme gebe: Das Invalidieren von Caches und das Benennen von Dingen – und Off-by-One-Fehler. Jede Entwicklerin und jeder Entwickler dürfte mindestens einem der drei genannten Probleme bereits begegnet sein, zumal gerade das Benennen von Dingen zum Arbeitsalltag gehören dürfte. Man denke beispielsweise an die Auswahl und die Vergabe von Variablennamen.

Mehr Infos

Götz & Golo

"Götz & Golo" ist eine gemeinsame Serie von Götz Martinek und Golo Roden. Der eine ist Geschäftsführer der sodge IT GmbH, der andere CTO der the native web GmbH. Was die beiden vereint, ist ihre große Leidenschaft für die Entwicklung von Software. Seit September 2019 nehmen sie sich monatlich ein Thema vor, zu dem dann jeder seine individuelle Perspektive beschreibt, ohne den Artikel des jeweils anderen im Vorfeld zu kennen. Der zugehörige Artikel von Götz findet sich im Blog von Sodge IT. Die Fragestellung zu diesem Beitrag lautete: "Programmieren in Deutsch oder Englisch?"

Doch selbst wenn man sich bemüht, lesbaren Code zu schreiben und fachlich beschreibende Variablennamen wählt, bleibt die Frage, in welcher Sprache man Variablen eigentlich benennen sollte. Das nächstliegende wäre, Bezeichner in der eigenen Muttersprache zu suchen, doch in vielen Projekten ist beispielsweise Englisch vorgegeben. Was spricht für das eine, was für das andere?

Zunächst ist festzuhalten, dass es leichter fällt, sich in der eigenen Muttersprache auszudrücken (im Folgenden gehe ich in dem Zusammenhang von Deutsch aus, da das meiner persönlichen Muttersprache entspricht). Man kennt nicht nur mehr Wörter, sondern man hat auch ein besseres Gefühl für die Bedeutung von Wörtern und deren feine Nuancen. Außerdem entspricht die Muttersprache im einfachsten Fall jener Sprache, in der man mit der Fachexpertin oder dem Fachexperten kommuniziert. Wer über ein Schachspiel spricht, kennt die Begriffe Bauer, Springer und Läufer – wer das auf Englisch machen möchte, muss die englischen Pendants kennen: pawn, knight und bishop.

Es fällt auf, dass es sich dabei nicht einfach um Übersetzungen handelt, sondern dass gänzlich andere Begriffe verwendet werden, die auch andere Bedeutungen assoziieren: Ein Bischof ist sicherlich etwas anderes als ein Bote. Während man bei einem Bischof vielleicht Würde und Macht assoziiert, denkt man bei einem Boten an Geschwindigkeit. Beides ist im Kontext des Schachspiels zulässig, zeigt aber verschiedene Hintergründe.

Hinzu kommen die sogenannten "falschen Freunde", also Übersetzungen, die richtig zu sein scheinen, tatsächlich aber falsch sind: Das englische Wort gift beispielsweise bedeutet Geschenk und nicht Gift. In real existierendem Code trifft man häufig auf das falsch übersetzte actualDate (statt currentDate) für das aktuelle Datum. Die Softwarearchitektur kennt die sogenannte eventual consistency, die immer wieder falsch mit eventuell konsistent (statt letztlich konsistent) übersetzt wird. Beispiele dieser Art gibt es zuhauf.

Das alles spricht dafür, auf die unnötige Übersetzung zu verzichten und Bezeichner im Code stattdessen mit Begriffen aus der Muttersprache zu belegen.

Allerdings funktioniert das nur bedingt. Zum einen wird man kaum eine Programmiersprache, eine Bibliothek oder ein Framework finden, das mit deutschen Begriffen arbeitet. Die sprachliche Vermischung wirkt dann rasch sehr merkwürdig und verursacht unter Umständen mehr Probleme, als sie löst, von der Verwendung von Unicode-Zeichen ganz abgesehen (Pseudocode):

importiere { promises als fs } aus 'fs';

konstante ermittleHosts = asynchrone funktion () {
sei inhalt;

versuche {
inhalt = erwarte fs.openFile('/etc/hosts');
} behandle {
inhalt = '';
}

sei hosts = inhalt.zerlege('\n');

gibZurück hosts;
};

Auch mehrsprachige Teams werden an derartigem Code keine Freude haben. Selbst wenn heute alle Mitglieder eines Teams die gleiche Sprache sprechen, muss das morgen nicht zwingend auch noch so sein. Außerdem beraubt man sich der Möglichkeit, Code effizient mit anderen im Web zu teilen, beispielsweise auf Plattformen wie Stack Overflow.

Englisch ist schlicht und ergreifend verbreiteter. Die Wahrscheinlichkeit, Entwicklerinnen und Entwicklern zu begegnen, die Englisch sprechen, ist weitaus höher, als für nahezu jede andere Sprache. Wer schon einmal unfreiwillig Quellcode mit Kommentaren in einer nicht bekannten Fremdsprache erhalten hat, weiß, wie unpraktisch das ist.

So gesehen ist auch die Verwendung von Esperanto keine Lösung – die Verbreitung der Sprache ist schlichtweg zu gering, weshalb sie im Vergleich zu Englisch stets im Nachteil ist.

Es liegt also nahe, die Schlussfolgerung zu ziehen, jeglichen Code und alle Kommentare auf Englisch zu schreiben. Doch das greift auch wieder zu kurz: Während das für ein Schachspiel noch funktionieren mag (schließlich lassen sich die englischen Begriffe im Zweifelsfall rasch nachschlagen), gibt es Fachdomänen, für die das nicht oder zumindest nicht ohne großen Aufwand möglich ist.

Das ist zumeist dann der Fall, wenn ein Themengebiet inhaltlich mit einem Land oder einem Sprachraum verbunden und nicht international gültig ist. Das gilt beispielsweise für zahlreiche juristische Aspekte, aber auch für das Steuer- und Finanzwesen eines Landes. In solchen Fällen kann es also durchaus sinnvoll sein, für die Fachbegriffe bei der ursprünglichen Sprache der Fachdomäne zu bleiben.

Dem entgegen steht allerdings das Argument, dass man bei einer hinreichend komplexen Fachdomäne ohnehin auf ein Glossar oder etwas Ähnliches angewiesen ist – ob man nun die Erklärung für einen englischen oder einen deutschen Begriff nachschlägt, die einem ohne Glossar nichts sagen, macht letztlich keinen allzu großen Unterschied.

Wie man sieht, gibt es keine allgemein gültige Antwort auf die Frage, in welcher natürlichen Sprache man Code schreiben sollte. Es gibt gute Argument für die eigene Muttersprache, aber auch Argumente für Englisch als gemeinsamen Nenner. Grundsätzlich muss abgewogen werden, in welchem Verhältnis Aufwand und Nutzen zueinander stehen – und diese Bewertung wird von Team zu Team und von Projekt zu Projekt unterschiedlich ausfallen.

Persönlich verwende ich – außer in sehr gut begründeten Ausnahmefällen – durchweg Englisch, da wir bei the native web häufig mit internationalen Kunden zu tun haben und darüber hinaus sehr viel Software als Open Source veröffentlichen. In beiden Fällen kämen wir mit Deutsch nicht allzu weit.

tl;dr: Ob man auf Deutsch oder auf Englisch programmieren sollte, lässt sich nicht allgemein gültig beantworten. Für die Muttersprache hat man das bessere Sprachgefühl, mit Englisch ist man aber in internationalen Teams, bei Open Source und im Austausch mit der Community besser aufgestellt. Außerdem hängt die zu verwendende Sprache stark von der Fachdomäne ab. ()