Domänenspezifische Funktionsnamen

Lesetipps

1. Bewerbungsgespräche, noch eine Vorgehensweise

Ich glaube mit der Artikelüberschrift gewinne ich wohl keinen Blumentopf. Will ich heute auch gar nicht, mag eh keine Blumen. Was ich aber mag ist eure Meinung, die will ich heute nämlich einholen. Anders als sonst, werde ich euch nicht einfach eine Nilsche Theorie an den Kopf werfen, sondern will heute mal eine Frage loswerden.

Eigentlich ist es auch eine ganz einfache Frage, an der ich aber immer mal wieder knabbere. Es geht um Funktionsnamen. Johannes hatte vor kurzem in einem seiner Blogpost das Thema mal wieder angeschnitten und ich will es aufgreifen. Die Frage: Darf ich deutsche Funktionsnamen haben? Wenn ich kurz drüber nachdenke, dann würde ich sagen, ein ganz klares NEIN. Wenn ich länger drüber nachdenke, dann würde ich sagen VIELLEICHT. Was ging also in der etwas längeren Nachdenkphase in meinem kleinen Hirn vor?  Naja ich arbeite für einen Verlag. Wir haben ein eigenes Wörterbuch für Absätze, Überschriften und andere Texte. So heißt zum Beispiel die kleine Überschrift über der Überschrift Spitzmarke – glaube ich zumindest. Falls nicht, tut’s mir leid.

Jetzt schreibe ich eine Funktion, die eine Spitzmarke setzt. Wie nenne ich die denn jetzt? Leo.org gibt mir mal gar keinen Anhaltpunkt. Macht umschreiben Sinn? Denke nicht. Wenn ich im anfange mit SetHeadlineAboveHeadline( ), geht das ja mal gar nicht. Bei setSpitzmarke( ), bekomme ich aber auch Gänsehaut. Die ist aber nicht ganz so groß, wie bei der ersten Version.

Und genau hier kommt ihr ins Spiel. Wie geht ihr denn mit solchen domänenspezfischen Ausdrücken um? Früher war ich echt sicher, dass man immer im Englischen bleiben soll. Das würde ich eigentlich auch so unterstreichen. Darf es aber Ausnahmen geben? Ich hab echt keine Ahnung. Ich tippe mal drauf, dass viele von euch die gleichen Problem haben, denn jede Branche hat seine eigenen Fachwörter, die man nicht immer in eine fremde Sprache überführen kann.

32 Kommentare »

• 
  

  oliver

  am 31. Juli 2009 um 07:48 Uhr

  wenn es wirklich keinen sinnvollen englischen namen für die funktion gibt nutze ich auch deuteche nemen eh ich übermäßig abstrakte funktionsnamen habe, das ist aber auch ziemlich selten der fall, da es ja meißtens eher so ist das ein deutscher funktionsname lang und abstract wird

• 
  

  Robert Kummer

  am 31. Juli 2009 um 08:12 Uhr

  Also ich verwende ausschließlich englische Namen für Methoden und Klassen. Damit breche ich eigentlich nur auf Kundenwunsch…bisher hatte ich damit auch keine Probleme.

• 
  

  Tyco

  am 31. Juli 2009 um 08:21 Uhr

  Ein ähnliches Problem hatte ich auch mit optischen Begriffen. “Sphäre”, “Zylinder” und “Addition” waren ja noch leicht zu übersetzen. Mit Begriffen wie “Entspiegelung”, “Hartschicht” und “Planglas” hatte ich dann schon meine Probleme.

  Im Endeffekt bin ich aber dabei geblieben, alles ins Englische zu übersetzen, ua. wegen der Möglichkeit der Internationalisierung (damit zB. ein Ungar auch eine Chance hat, den Source zu verstehen).

  Ich denke, dass es stark auf die Domäne ankommt. Typographie ist traditionell eine eher “deutsche” Disziplin, von daher spricht nichts dagegen, auch die Bezeichnungen zu übernehmen. In der Optik hingegen gibt es klare internationale (also englische) Bezeichnungen. Es kommt überhaupt darauf an, auf welches Vokabular man sich im Team einigt. Wenn man projektintern dazu “Spitzmarke” sagt, ist es fast witzlos, es dann nachher mit “Catchline” oder “Slug” zu übersetzen, weil dann die Bedeutung nicht für jeden klar ist.

• 
  

  Tobi

  am 31. Juli 2009 um 08:44 Uhr

  Kenne das Problem. Bei einigen Sachen machts dann aber echt keinen Sinn das dann irgendwie ins Englische umzuschreiben. Ich mein die Lesbarkeit ist halt entscheidend und wenn ich nachher dreimal hinschaun muss bringts das dann auch nicht.

  Grüße
  Tobi

• 
  

  Ulf

  am 31. Juli 2009 um 08:48 Uhr

  Die wichtigste Frage die sich stellt. Wer wird diesen Code lesen? Wenn auch Nicht-Deutschsprachige diesen Code lesen müssen, dann kannst du auch nie deutsche Funktionsnamen verwenden! Dann musst du eben wirklich die Spitzmarke umschreiben. Und ich bin mir sicher, dass es dafür einen domänenspezifischen Namen gibt wie z.B. setSubheadline. Grundsätzlich gibt es doch alle Begriffe auch im Englischen, weil sowohl Deutsch als auch Englisch nur Formen von Sprachen sind.

  Viele Grüße
  Ulf

• 
  

  Nils Langner

  am 31. Juli 2009 um 09:08 Uhr

  Wenn ich das englische Wort kenne oder es schnell rausfinden kann, dann ist die Antwort klar. Aber es gibt eben Worte, die nicht auf Leo zu finden sind.

• 
  

  Spider

  am 31. Juli 2009 um 09:18 Uhr

  Schwierige Sache, es wird immer Anwender und Leser geben die Probleme damit haben werden, diese Funktion, nur an Hand des Funktionsnamen, korrekt zu interpretieren.
  Hier ist dann mehr als sonst eine gute Dokumentation und ein ausführliches Kommentar von Nöten.

  Ich persönlich würde dann wohl zur englischen Variante tendieren, einfach weil sich bei mir alle Haare, bei der deutschen Version, sträuben

  Zum Glück hab ich dieses Problem nicht, da meine Arbeit wirklich zu 100% eine englische Domäne ist.

  Gruß,
  -Spider

• 
  

  Michael Haszprunar

  am 31. Juli 2009 um 09:21 Uhr

  Bitte nix Deutsches! Nicht weil es blöd klingt, sondern weil man den Code dann kaum mit anderen teilen kann. Es regt mich imemr shcon so auf wenn man französischen Code kriegt. Da kann man nicht mal die Variablennamen lesen, geschweige denn den Code oder die Fehlermeldungen *ARGH*

• 
  

  Martin Kuckert

  am 31. Juli 2009 um 09:27 Uhr

  Ich würde versuchen die Begriffe der Domäne in ein eigenes Vokabular englischer Begriffe zu überführen. Du übernimmst ja auch nicht jede Lösung aus der Domäne, nur weil diese üblich ist. Hier machst du dir ja auch über die Optimierung von Vorgängen etc. gedanken. Und wenn du die Problemlösung schon auf eine abstraktere Ebene hebst um diese besser betrachten zu können, würde ich mich auch von den üblichen Begriffen trennen. In der GUI kannst du diese ja wieder aufgreifen, das ist dann aber ein Thema der Lokalisierung und geht dich damit nur zweitrangig etwas an.

• 
  

  Markus

  am 31. Juli 2009 um 09:29 Uhr

  Ich bin mittlerweile vom Deutschen zum Englischen gewechselt und hatte bis jetzt keine Probleme. Die CamelCase-Schreibweise war mir viel wichtiger, als die Benennung der Funktionen. Eine einheitliche Schreibweise egal ob in de oder en kann jedem helfen – nur der einleitende Kommentare sollten dann englisch sein

• 
  

  Steffkes

  am 31. Juli 2009 um 09:32 Uhr

  Sollte sich doch eigentlich relativ einfach lösen lassen .. wenn man Kollegen hat, die sich nicht in Deutschland befinden – dann werden die für das entsprechende Wort ja auch eine Übersetzung haben .. vllt sogar eine Englische?

• 
  

  Stephan Hochdoerfer

  am 31. Juli 2009 um 09:32 Uhr

  Wäre eine Art Data Dictonary auf einer Wiki-Seite oder in der Code-Dok nicht eine Hilfe um in ein, zwei Sätzen zu erklären was eine “Spitzmarke” ist?

• 
  

  Martin

  am 31. Juli 2009 um 09:40 Uhr

  Ein Dictonary wäre eine gute Möglichkeit zu erklären, dass mit Slug die Spitzmarke gemeint ist. Aber niemals anders herum.

• 
  

  Nils Langner

  am 31. Juli 2009 um 09:40 Uhr

  Ok, also der Grundtenor scheint wohl zu sein, dass man die englische Sprache immer vorzugsweise benutzen sollte, solange es geht.
  Ein Wörterbuch mitzuliefern wäre natürlich eine gute Idee. Die Abstraktionsebene von Martin finde ich auch nicht verkehrt.

• 
  

  LudwigR

  am 31. Juli 2009 um 10:20 Uhr

  Spitzmarke wird auch Dachzeile genannt, dies wiederum führt einem zu:
  http://dict.leo.org/forum/viewUnsolvedquery.php?idThread=100026&idForum=1&lp=ende&lang=de

  Klar sollte man englische namen bevorzugen, aber wenn man wirklich in der zwickmühle steckt kann man doch auch deutsch nehmen, für was gibts den kommentarblock (in englisch natürlich). Hauptsache die methoden haben die richtigen prefixe. damit die IDE die methode nebst kommentar auch anzeigt.

  my2c

• 
  

  Dennis Becker

  am 31. Juli 2009 um 10:26 Uhr

  Ich bin auch der Meinung, man sollte englische Begriffe so weit es möglich ist verwenden oder eine Art Umschreibung benutzen, die kurz und Prägnant ist. Ein passender Kommentar sollte eigentlich eh alles dazu klären.

• 
  

  Erjaa

  am 31. Juli 2009 um 10:27 Uhr

  Vielleicht sollte Spitzmarke auch einfach übernommen werden. Gerade im Englischen gibt es etliche deutsche Begrifflichkeiten. Diese wurden übernommen das sie einfach vieles präziser beschreiben. Ich glaube der Nullstellensatz gehört auch dazu, sowie Fingerspitzengefühl in der Abwandlung Fingertipsfeeling (! kein echtes englischeswort). Mehr davon:
  http://de.wikipedia.org/wiki/Liste_deutscher_W%C3%B6rter_im_Englischen

• 
  

  Blackflash

  am 31. Juli 2009 um 11:24 Uhr

  Um die Frage zu beantworten, muss man sich, wie bereits erwähnt, fragen, wer diesen Code lesen muss. Sind es Personen, die in der Domäne arbeiten? Vor allem für domänenspezifische Sprachen, die bisher außer Acht gelassen wurden, kann es sehr hilfreich sein, wenn direkt die Begriffe aus der Domäne verwendet werden. Sind die Verwender jedoch andere Programmierer, sollte man englische Begriffe bevorzugen – weil es eben Standard ist. Diesen Standard kann man natürlich brechen, wenn das Projekt nur intern verwendet wird, aber das ist wohl Geschmackssache. Mir würde es jedenfalls nicht in den Sinn kommen, deutsche Vokabeln beim Programmieren zu verwenden…

  Es gibt tatsächlich mehr Germanismen im Englischen als man erwarten würde, aber man sollte nicht neue Germanismen einführen und hoffen, dass sich diese durchsetzen. Der Punkt ist Konformität zur sprachlichen Situation. In einem Meeting würde man schließlich auch nicht plattdeutsch sprechen, sondern so, dass man sich leicht versteht.

• 
  

  Heiko

  am 31. Juli 2009 um 11:27 Uhr

  Tja, persönlich bin ich der Meinung das man bei Englisch bleiben sollte. Es sieht immer merkwürdig aus wenn bei einer Programmiersprache die ja alle Englisch als “Grundsprache” benutzen (z.B. if, for, else das “böse” goto usw.) dann auf einmal deutsche Begrifflichkeiten auftauchen. Und wenn man seinen Quelltext mal an einen englischsprachigen Kollegen weitergeben sollte, kann der unter Umständen nicht viel mit den deutschen Begriffen anfangen.

• 
  

  Heiko

  am 31. Juli 2009 um 11:52 Uhr

  Wie hält man/Ihr es denn dann mit Kommentaren ? Alle in Englisch oder die dann doch in Deutsch ?

• 
  

  Blackflash

  am 31. Juli 2009 um 12:13 Uhr

  Wenn der Code nicht für die Außenwelt bestimmt ist, kommentiere ich auf Deutsch. Das ist für mich bequemer und ich kann dadurch schneller schreiben, da ich diese Sprache besser beherrsche als Englisch. Das mag sich vielleicht relativieren, wenn man täglich auf Englisch schreibt, aber da ich mittlerweile sehr unregelmäßig programmiere, würde sich ein Umstellen auf Englisch nicht lohnen.
  Für das Verständnis sollte sich die Muttersprache sowieso positiv auswirken.

• 
  

  Martin Kuckert

  am 31. Juli 2009 um 12:22 Uhr

  Meine Kommentare sind in deutsch verfasst. Erstmal wären diese im englischen wahrscheinlich nicht ganz so ausführlich, ist eben was anderes als die Muttersprache. Und dann wird das Projekt in der Regel nicht von anderen Programmieren, welche nicht deutschsprachig sind, genutzt. Man könnte ähnlich für die deutsche Sprache in den Methodennamen etc. kommentieren, aber das ist dann doch was anderes.

• 
  

  Nils Langner

  am 31. Juli 2009 um 13:12 Uhr

  Aber ist das nicht ein Widerspruch? Namen müssen auf englisch sein, damit sie überall verstanden werden und dann die Kommentare auf deutsch? Bei mir sind die Kommentare immer auf Englisch, denn hier kann ich Begriffe, deren Übersetzung ist nicht kenne einfacher umschreiben.

• 
  

  maren

  am 31. Juli 2009 um 14:08 Uhr

  Ich würde es so halten, wie ich es mit meiner Sprache im allgemeinen halt.
  Ich versuche in der Fachterminologie so deutsch wie möglich zu schreiben, aber wenn im deutschen kein wirklich passender Begriff vorhanden ist, verwende ich die englische Terminologie.

  Beim programmieren Versuche ich beim englischen zu bleiben und bisher ging es auch gut. Mag aber daran liegen, dass wir nicht so Domänen-spezifisch arbeiten.

• 
  

  Martin

  am 31. Juli 2009 um 14:18 Uhr

  Da man im Vorfeld nicht wissen kann, wer sich den Sourcecode wann anguckt bin ich dafür alles in Englisch zu schreiben.
  Wenn Wörter im Deutschen identisch mit dem Englischen sind kann man natürlich deutsche Wörter verwenden
  Das Problem mit domänbezogenen Begriffen ist ja, dass man sich nie sicher sein kann, ob und wann der Leser des Sourcecode aus der Domän kommt. Insofern würde ich dazu raten ggf. ein projektbezogenes Data Dictonary anzulegen und dort Begriffe zu erläutern, wenn man mit der Leo Übersetzung nicht zufrieden ist.

• 
  

  Blackflash

  am 31. Juli 2009 um 14:45 Uhr

  @Nils: Vielleicht sieht es tatsächlich wie ein Widerspruch aus, aber es ist keiner. Wenn der Code für die Außenwelt ist, sollte man ausschließlich Englisch verwenden – da gibt es keine Diskussion. Ist der Code nicht für die Außenwelt bestimmt, verwende ich bei der Programmierung ausschließlich englische Ausdrücke und kommentiere aus o.g. Gründen auf Deutsch. Ich habe ja bereits gesagt, dass ich bei internen Projekten bei der Programmierung genauso gut Deutsch verwenden könnte, aber das tu ich aus Geschmackssache einfach nicht. Das liegt daran, dass es mir bei der Programmierung um Konzepte und bei der Dokumentation um Erklärungen geht. Die Konzepte, von denen ich spreche, sind mental und sprachunabhängig, weshalb die Sprache bei der Bezeichnung nicht von entscheidender Bedeutung ist. Es ist sogar vorteilhaft, wenn man nicht die Muttersprache wählt, da man dadurch Missverständnissen, die einem allzu bekannte Wörter suggerieren, vorbeugen kann. Außerdem ist der Quelltext dann konsistent wie Heiko bereits gesagt hat. Bei domänenspezifischen Problemen muss man sich nach der voraussichtlichen Zielgruppe richten.

  @Martin: Nimmst du immer einen Regenschirm mit?

  Mit einem Data Dictionary ist man zumindest auf der sicheren Seite. Mit Quelltext, der nur englische Ausdrücke enthält, ist man auch auf der sicheren Seite, aber es rechnet sich nicht unbedingt von Anfang an.

• 
  

  Nils Langner

  am 31. Juli 2009 um 15:01 Uhr

  @Blackflash: Die Regenschirm Frage müsstest du in Hamburg umformulieren

• 
  

  Johnny

  am 1. August 2009 um 09:57 Uhr

  Was macht man bei deutscher Steuersoftware?

• 
  

  Johannes

  am 1. August 2009 um 14:16 Uhr

  So lange alle Kommunikation mit dem (internen) Kunden auf deutsch ist und deutsche Terminologie verwendet die Domänen-spezifisch ist ist es eine Qual das mit einer Übersetzung zu handhaben.

  Zudem ist es deutlich wahrscheinlicher, dass die Anwendung von jemandem übernommen wird, der deutsch kann und die deutsche Spec bekommt als das nicht. Und wenn das outgesourced wird kann der Entwickler das einfach als Eigennamen sehen und gut.

  Sicher es gibt Fälle wo man so eine Software dann rausgibt aber dann muss man ja auch das Userinterface usw. lokalisieren und evtl. ein paar spezielle Dinge verallgemeinern, da kann man sich dann auch um sowas kümmern … wobei dann halt die Frage ist ob sich der erhöhte Pflegeaufwand auch nur irgendwie lohnt.

  In dem Bereich wo ich tätig war handelte es sich um Software zur Bilanzanalyse – da hat man es mit Fachterminologie zu tun für die es zwar Übersetzungen gibt nun funktioniert aber US GAAP anders als “deutsche” Bilanzierung so, dass bei manchen Übersetzungen der Code behaupten würde US GAAP Regeln zu befolgen was aber nicht der Fall ist. Da ist beibehalten der deutschen Begriffe deutlich sinniger.

  Oh und das Ding wurde initial von einem nicht-deutschen entwickelt — auch der hat die deutschen Begriffe verwendet.

  Achja, warum ist dieses Blog auf deutsch? – Man könnte einen großen Teil der Argumente hier genauso auf das Blog übertragen, dennoch ist es deutsch? Warum? – Richtig, weil es pflegeleichter ist und die Zielgruppe deutsch kann. qed.

  johannes

• 
  

  Martin

  am 1. August 2009 um 23:21 Uhr

  Die Sprache der Kommentare von der Funktionalität der Software abhängig zu machen klingt aber nicht sehr sinnvoll. Wenn dann die Stellen im Sourcecode für USA in Englisch, für Frankreich in Französich und für Deutschland in Deutsch sind, erhöht das meiner Meinung nach nicht die Verständlichkeit. Ich glaube auch kaum, dass ein Inder, der für SAP das dt. Steuerrecht implementiert, Deutsch lernt dafür. Dass man Eigennamen so läßt wie sie sind, mag so sein, ändert ja aber an der Verwendung von Englisch nichts.
  Aber wie soll man eine komplett deutsche Kommentierung als Eigenname sehen?
  Ich sehe auch irgendwie keinen Vorteil von deutschen Kommentaren. Im Gegenteil beugt es vielleicht Belletristik im Sourcecode vor, wenn nicht native Speaker English schreiben.
  Damit will man ja auch nicht alle Kommunikation der Welt gleich schalten, sondern nur sicherstellen, dass all die Millarden Menschen auf der Welt das Stück Meisterwerk an Software, was man erstellt auch verstehen. Wenn man natürlich nur irgendein Hinterhof-Klitsche-Workaround-Hack schreib, den man in einer Woche selbst nicht mehr braucht/versteht/verwenden will, kann man sich Kommentare wohl eh sparen.

• 
  

  Johannes Schlüter

  am 3. August 2009 um 19:30 Uhr

  Code and human languages…

  In a previous blog post I mentioned the possibility for using non ASCII characters as part of identifiers. Nils Langner, who runs the German "PHP hates me (but that’s ok)" blog, then wondered whether it makes sense to use German (in his ca…

• 
  

  Peter

  am 30. Juli 2010 um 11:39 Uhr

  Ich mache es abhängig vom Projekt/Kunden.
  Ist der Kunde/das Projekt international und ist davon auszugehen, dass andere oder spätere Projektmitarbeiter des deutschen nicht mächtig sind, dann ganz klar auf englisch.
  Funktionsnamen wie Kommentare.

  Ist bei einem Projekt davon auszugehen, dass es nur im deutschen Sprachraum genutzt wird, sehe ich auch keine Probleme deutschen Funktionsnamen. PHP ist es egal, was es zu interpretieren hat. Je einfacher, prägnanter und beschreibender der Funktionsname ist, desto einfacher ist es, den Quelltext später wieder zu lesen. Und das sollte ja schließlich auch ein Argument beim Design sein.

  Die Mischung aus engl. und deutschen Elementen wie set_spitzmarke() oder get_bildliste() sehe ich bei einem reinen deutschsprachigen Projekt nicht als Hindernis.

  Die Erstellung eines Styleguides für die Regelung solcher Fragen für alle Projektbeteiligten sollte dagegen bei größeren Projekten durchaus in Erwägung gezogen werden.

RSS Feed für Kommentare zu diesem Artikel. TrackBack URL

Hinterlasse einen Kommentar