Kommentare zu: Domänenspezifische Funktionsnamen

Von: Peter

Peter — Fri, 30 Jul 2010 09:39:18 +0000

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.

Von: Johannes Schlüter

Johannes Schlüter — Mon, 03 Aug 2009 17:30:27 +0000

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…

Von: Martin

Martin — Sat, 01 Aug 2009 21:21:01 +0000

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.

Von: Johannes

Johannes — Sat, 01 Aug 2009 12:16:37 +0000

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

Von: Johnny

Johnny — Sat, 01 Aug 2009 07:57:07 +0000

Was macht man bei deutscher Steuersoftware?

Von: Nils Langner

Nils Langner — Fri, 31 Jul 2009 13:01:51 +0000

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

Von: Blackflash

Blackflash — Fri, 31 Jul 2009 12:45:40 +0000

@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.