Programmieren in Deutsch oder Englisch?

Eine Frage, die immer mal wieder aufkommt, ist: Programmieren in Deutsch (stellvertretend für $Muttersprache) oder in Englisch?
Gemeint ist damit, in welcher Sprache Variablen, Methoden oder sonstige Bezeichner und Kommentare geschrieben werden.
Die Antwort hierauf lautet: "Am einfachsten in Englisch!"

Aber warum?

Was man sich immer vor Augen führen sollte: Wenn etwas geschrieben wurde, wird es früher oder später auch gelesen. Dann wäre es natürlich von Vorteil, wenn die Hürde für den Lesenden so niedrig wie möglich ist. Nur so hat jemand die Chance, sich einzuarbeiten und gegebenenfalls Fehler oder Verbesserungen durchzuführen.
Je nachdem, mit wem man alles zusammenarbeitet, ist Englisch meistens der gemeinsame Nenner, egal auf welchem Sprachniveau.
Und je länger eine Software lebt, desto größer ist die Chance, dass sie mit einem Nichtmuttersprachler in Berührung kommt.

Was man auch nicht unterschätzen sollte, ist die Macht der Gewohnheit. Wenn ich Methoden sehe, die mit "Setze" und "Gib" anfangen, bringt das meine Mustererkennung kurzfristig durcheinander. Das stört die einfache Lesbarkeit, da es für mich etwas Unerwartetes ist.

Neben der Verständlichkeit und der Gewohnheit kommt es auch vor, dass ein eingesetztes Tool nicht mit bestimmten Sonderzeichen klarkommt. Natürlich kann man z. B. die Umlaute umwandeln in "einfacher Vokal + e". Erfahrungsgemäß wird sich aber früher oder später ein Fehler einschleichen. Im Idealfall fällt das dann dank CI/CD-Systemen früh auf – im Idealfall.
Das hat jetzt nicht direkt etwas mit Bezeichnern zu tun, da für diese meist genau definiert ist, welche Zeichen genutzt werden dürfen. Allerdings können auch Kommentare manche ältere oder Custom-Inhouse-Tools in den Abgrund stürzen.

Ein vollkommen nachvollziehbarer Reflex: "Dann wirf doch so alte Tools raus!" Nur leider gibt es immer noch Konstellationen, in denen solche Tools eingesetzt werden müssen und ein Wechsel momentan noch nicht wirtschaftlich ist, oder anders gesagt: in denen das Problem noch nicht genug Schmerzen verursacht.
Vermutlich werden uns solche Probleme auch noch eine Weile begleiten, denn wenn ich im Jahr 2020 ein interessantes "Infrastructure as Code"-Framework ausprobieren will, das mir beim Build einen Fehler aufgrund von Umlauten in Statusmeldungen meines Compilers liefert. *seufz*
Eigentlich war ich hier optimistischer ... aber es folgte der Realitätscheck inklusive zwei Stunden Recherche und "Kopf auf Tisch". ;)
Vielleicht müssen wir heute die Probleme einfach im Vorfeld schon minimieren, mit plain-old ASCII. Noch sind wir wohl nicht im gesamten Technologiestack so weit, so traurig wie das klingt.

Aber wir haben doch UTF?

Ja – und IPv6.
Okay, vielleicht etwas gemein. In der Zwischenzeit geht das ganz gut mit IPv6, aber irgendwie hat das gepasst. ;)
UTF als Encoding von Unicode bietet die Möglichkeit, in variabler Länge alle möglichen Zeichen zu kodieren. Im Gegensatz zu ASCII scheint die Menge der zur Verfügung stehenden Zeichen wohl ausreichend zu sein. Wenigstens bin ich zu diesem Schluss gekommen, nachdem ich im Unicodezeichensatz einen "Pile of Poo" entdeckt habe (U+1F4A9).
Die gute Nachricht: Im Web ist UTF das meistgenutzte Encoding. Hier sind auch viele Tools super darauf ausgelegt, aber je weiter man sich der Hardware nähert, desto umständlicher wird es.
Vermutlich auch, weil hier einfach die älteren Tools zu finden sind.

Weitere Infos gibt es bei dem Klassiker The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!).

Folgefragen

Kaum, dass jemand die obige Frage für seinen Bereich besprochen hat, kommen die gleich nächsten ...

• Welche Sprache in Tickets?
  Kommt sehr auf die Zusammensetzung des Teams an, aber auch hier plädiere ich ebenfalls aus obigen Gründen für Englisch.
• Welche Sprache in Commitmessages?
  Vermutlich ist die Antwort hierauf auch vorhersehbar ... Englisch. Viel wichtiger als die Sprache ist mir bei dem Thema Commitmessages jedoch: "Was soll drinstehen?"
  Für den einen oder anderen Schmunzler oder andere Reaktionen kann man sich auf whatthecommit.com umschauen.
• Welche Sprache in Threads/Kommunikation?
  Ja ... auch hier bin ich der Meinung, dass Englisch eine gute Basis bietet. ABER sollte die Teamzusammenstellung es erlauben, dann sollten umfangreiche und tiefe Diskussionen in der entsprechenden Muttersprache verfasst werden. Hier ist für alle Beteiligten viel klarer, über was exakt geredet wird, und feine Unterschiede bei Bedeutungen von Wörtern können helfen, den Kern der Diskussion freizulegen.
  Eine Zusammenfassung kann ja wieder in Englisch verfasst werden. Oder man weicht auf mündliche Kommunikation zur Entscheidungsfindung aus. Was so oder so in hitzigen Diskussionen entscheidend hilft. :)

Eine völlig korrekte Anmerkung eines Kollegen war: "Was ist, wenn ich nicht wirklich gut Englisch kann? Manchmal ist es ja schon schwierig, z. B. Kommentare in der Muttersprache sinnvoll zu verfassen."
Hmm ... stimmt. In diesem Fall ist es vermutlich besser, in der Muttersprache zu kommentieren und eine mögliche Übersetzung einem $Webdienst zu überlassen oder Englisch zu lernen. ;)

Wie üblich ist aber das alles keine "One size fits all"-Regel. Je nach Team, Sprachkenntnissen, Firmengröße, Kundenkreis, Partnerschaften ... sind völlig andere Regelungen möglich und auch sinnvoll.
Was man bei der Entscheidungsfindung aber bitte rauslassen sollte, sind (Lokal-)Patriotismus oder Angst vor Sprachverlust.

Man sollte aber immer bedenken, dass man nie wissen kann, wer mit dem Projekt in Berührung kommt und daran arbeiten will oder muss. Und unabhängig davon, ob ich den/die/* spätere/n/* Entwickler/in/* kenne oder nicht, kann ich ihm/ihr/* ja in gewisser Weise auch helfen. Wohlwissend, dass sich sicher auch über das eine oder andere, was ich entwickelt habe, "gewundert" wird. ;)
Aber so kann ich wenigstens mit verständlichen und lesbaren Variablen, Methoden und Kommentaren einen positiven Eindruck hinterlassen – selbst wenn ich schon längst in Rente bin.

Ein Kollege hatte vor ca. 20 Jahren Code aus Malaysia zur Erweiterung und Fehlerbehebung mit Variablennamen und Kommentaren in Malaysisch, geschrieben mit lateinischen Buchstaben ...
Rückblickend eine lustige Geschichte, aber damals nur eine unnötige Hürde. Und ein wichtiger Punkt im Teamspiel "Softwareentwicklung" ist "Hürden niedrig halten".