spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Ich habe eben doch noch mal über den Code geschaut. Ein No-Go ist das Deklarieren von ArrayList als Parameter- oder Rückgabetyp, wenn Du auch List o.Ä. deklarieren kannst. http://stackoverflow.com/questions/14746…ass-be-prefered

Wenn Dich so allgemeine Qualitätsmerkmale an Deinem Code interessieren, kannst Du auch mal http://www.sonarqube.org/ drüber jagen. Mindestens PMD hat für solche Sachen ne Regel. Kannst natürlich auch nur sowas wie das PMD Plugin bei Dir in Eclipse installieren.

Hab nicht alles gelesen, aber was mich an dem Beispiel sofort stoert ist Deutsch im Code. Normalerweise verwendet jede firma englische bezeichungen im Code slebst. (Kommentare ausgenommen)

Zitat von »fkrauthan«

Hab nicht alles gelesen, aber was mich an dem Beispiel sofort stoert ist Deutsch im Code. Normalerweise verwendet jede firma englische bezeichungen im Code slebst. (Kommentare ausgenommen)

Kann ich nicht bestätigen. Es mach häufig Sinn das Vokabular des Kunden oder der Domänenexperten zu nutzen, es geht da auch um das Entwickeln eines gemeinsamen Wortschatzes. Wenn da im Unternehmen dann nun mal Deutsch vorherrscht ist es kontraproduktiv für alle Begriffe englische Entsprechungen zu finden, die eh keiner benutzt.

Ausnahmen bestätigen die Regel? Bei uns ist alles englisch, inklusive der Kommentare. Wer schon mal Code aus Rumänien übernehmen musste, der komplett rumänisch kommentiert ist und viele rumänische Bezeichner enthält, weil niemand je gedacht hat, dass der Source mal nach Deutschland wandert, der weiß, dass alles außer Englisch eine furchtbare Katastrophe ist.

Genau.

Die Frage ist doch lediglich, ob man die Kommunikation innerhalb des Teams und mit den Kunden wegen dieser zukünftigen Möglichkeiten erschweren möchte. Sobald es um etwas kompliziertere Domänen geht, in denen Englisch im Ursprungsland der Software nicht etabliert ist, wird man meiner Erfahrung nach immer muttersprachliche Bezeichner finden - einfach weil es einen zu großen Mehraufwand bedeuten würde Fachwörterbücher zu wälzen und den Fachexperten eine neue Sprache anzugewöhnen damit man auch mal Prozessmodelle und UMLs vorlegen kann.

Wie gesagt, wenn das jedes Land so macht, ist Software nicht global wart- oder erweiterbar. Egal wie lokal eine Geschichte ist, Software-Entwicklung selbst ist meiner Erfahrung nach ganz schnell eine globale Geschichte, auch für lokal ansässige Unternehmen. Die Hürde ist an der Stelle mMn viel größer als ein englischsprachiges Glossar zu pflegen, was ohnehin in jede Software-Dokumentation gehört.
Man weiß *nie* was die Zukunft bringt. Zudem existiert ein Unterschied zwischen den Bezeichnern, die man im Code einsetzt und denen, die der Kunde in seinem Betrieb verwendet. Von den Bezeichnern im Code wird der Kunde selbst ohnehin selten etwas sehen.

Da sind wir dann geteilter Meinung. Dass alle die gleiche Sprache benutzen und auch das Fachglossar im Code wiederzufinden ist, halte ich für sehr wichtig. In internationalen Projekten existiert sowieso ein englisches Glossar. Wenn man nach Indien outsourced o.Ä., dann ist das für mich ein internationales Projekt. Sofern die Auftraggeber und Domänen-Experten auch mit englischen Begriffen arbeiten können/wollen, ist es natürlich geboten Englisch zu schreiben, aber das ist eben nicht immer so.

Viel schlimmer ist es, wenn englische Fachbegriffe falsch bzw. willkürlich eingesetzt werden und jede Interessengruppe darunter dann etwas ganz eigenes versteht. Je größer der Interpretationsspielraum desto schlechter.

Zitat von »BlueCobold«

Zudem existiert ein Unterschied zwischen den Bezeichnern, die man im Code einsetzt und denen, die der Kunde in seinem Betrieb verwendet. Von den Bezeichnern im Code wird der Kunde selbst ohnehin selten etwas sehen.

Genau das wird in Domain-driven Design mMn völlig zurecht angemahnt. Es führt doch nur zu Missverständnissen und Fehlern, wenn man eine sprachliche Parallelwelt durch fachfremde Techniker aufbaut. Techniker müssen dann nicht nur die Domänenexperten verstehen und fachliche Konzepte in Code übersetzen, sondern auch in der Fachwelt etablierte Begriffe im Englischen identifizieren und schlimmstenfalls neu erfinden. So entstehen gravierende Fehlerpotentiale in der Kommunikation im Projektteam und auch darüber hinaus.

Es gibt leider genug große deutsche Unternehmen, die zwar genau wissen wie global ihre Branche ist, aber trotzdem auf Deutsch bestehen. Hatte letztens mit einem Kunden zu tun, der Maschinen an einen großen deutschen Automobilhersteller liefert. Der Automobilhersteller hat ausdrücklich eine deutsche Oberfläche gefordert, obwohl die Maschine letztendlich in China stehen wird. Wir haben da extra nochmal nachgefragt, weil es auch eine englische Oberfläche gibt, aber die Begründung war ganz einfach: "Konzernsprache ist deutsch, sollen die Chinesen es lernen."