Bezeichnungen in deutsch oder englisch?

Ich habe nach kurzer Zeit konsequent auf englische Bezeichner umgestellt, weil ansonsten ein Mischmasch aus Englisch (externe Bibliotheken) und Deutsch entsteht.

Aber das hat mich gerade auf die Idee gebracht, deutsche Ausdrücke mit den englischen zu vergleichen:

struct   plan
class    bund
char     stab
int      zahl
short    kurz
long     lang
unsigned nat
include  hol
return   wirf

pointer  zeiger
array    feld
string   kette
vector   liste
list     knüpfe
node     glied
stream   strom
map      kartei

Beispiel:

#hol <eastrom>
#hol <liste>
#hol <kette>

nutze std::kette;

bund kunde {
offen:
    kunde(fest kette& name, zahl geld)
      : name_(name), geld_(geld) {}
    fest kette& name() fest  { wirf name_; }
    nat         geld() fest  { wirf geld_; }
    leer kassier(nat betrag) { geld_ -= betrag; }
geheim:
    kette name_;
    zahl  geld_;
}

bund auftrag {
offen:
    auftrag(fest kunde& von, nat preis)
      : von_(von), preis(preis) {}
    fest kunde& von() fest { wirf von_; }
    bool erfüllt() fest { wirf getan; }
    leer machfertig() { kunde_.kassiere(preis); getan = wahr; }
geheim:
    fest kunde& von_;
    nat  preis;
    bool getan;
};

muster<typ T>
T lese(fest stab *txt)
{
    std::raus << txt << ": ";
    T wert;
    std::rein >> wert;
    wirf wert;
}

zahl start(nat argz, stab **argw)
{
    std::liste<auftrag> atr;
    für (nat i=0; i<10; ++i) {
        kette name(lese("Kundenname"));
        zahl  geld(lese("Vermögen"));
        atr.dazu(kunde(name, geld), 1000);
    }
    für (std::liste<auftrag>::läufer l=atr.anfang(); l!=atr.ende(); ++l) {
        l->machfertig();
        std::raus << "Vermögen von " << l->name() << ": " << l->geld() << std::nz;
    }
}

#include <iostream>
#include <vector>
#include <string>

using std::string;

class client {
public:
    client(const std::string& name, int money)
      : name_(name), money_(money) {}
    const string& name () fest  { return name_;  }
    unsigned      money() fest  { return money_; }
    void take_the_money(unsigned amount) { money_ -= amount; }
private:
    std::string name_;
    int  money_;
}

class commission {
public:
    commision(const client& from, unsigned price)
      : from_(from), price(price) {}
    const client& from() const { return from_; }
    bool comply() const { return done; }
    void complete() { from_.take_the_money(preis); done = true; }
private:
    const kunde& from_;
    unsigned price;
    bool done;
};

template<typename T>
T read(const char *desc)
{
    std::cout << desc << ": ";
    T value;
    std::cin >> value;
    return value;
}

int main(int argc, char **argv)
{
    std::vector<commission> cms;
    für (nat i=0; i<10; ++i) {
        string name(read("client's name"));
        int money(read("assets"));
        cms.add(client(name, money), 1000);
    }
    für (std::vector<commission>::iterator it=cms.begin(); l!=cms.end(); ++l) {
        l->complete();
        std::cout << "assets from " << l->name() << ": " << l->money() << std::endl;
    }
}

867 zu 986 Zeichen (abzüglich Leerzeichen) zugunsten der deutschen Bezeichner.

Ich lag fast unter dem Tisch

drakon

Egal was ihr macht. Mischt das ganze nicht. Erst recht nicht in dem gleichen Bezeichner.
So etwas geht gar nicht:

API von Firma X schrieb:

HoehenProfilPath

Ja, wirklich wahr. So was gibts wirklich.

drakon schrieb:

Egal was ihr macht. Mischt das ganze nicht.

Allein dadurch, dass man C++ nimmt wird man dazu gezwungen, englisch zu nehmen.
" return wert " ist ja schon gemischt.

Marc++us

Das kann auch Nachteile haben, wenn man Begriffe aus einem deutschen Umfeld hat. Zum Beispiel Jura, oder Steuern. Da ist die Wahl der Attributnamen auf Englisch nicht immer so glücklich. Noch dazu wird's oftmals dann auch "Denglisch".

Bei einer Bibliothek ist sowas ja einfach, solange man sich in der abstrakten Daatenwelt bewegt. Sobald man aber auf einer Anwenderebene arbeitet, könnten englische Bezeichner eine zusätzliche(!) Fehlerquelle beim Verständnis von Code oder Modell sein.

Dravere

Marc++us schrieb:

Sobald man aber auf einer Anwenderebene arbeitet, könnten englische Bezeichner eine zusätzliche(!) Fehlerquelle beim Verständnis von Code oder Modell sein.

Oja. Mieter (Wohnung):

charterer?
hirer?
leaser?
lessee?
lodger?
renter?
tenant?

Amerikanisches oder englisches Englisch?

Da gibt es allerdings schon Abhilfe. Nicht zu selbstbewusst sein, Kollegen fragen, sich genauer informieren, am besten in Texten, sich halt eben etwas mehr Zeit nehmen und dann den richtigen Namen auswählen. Sowas sollte man sowieso zum Teil mehr tun, sich Zeit lassen bei der Namenswahl, denn dies kann auch stark zum Verständnis des Codes beitragen.
Ich bin jedenfalls grundsätzlich für Englisch. Schon nur wegen der Standardbibliothek und den ganzen Schlüsselwörtern, welche alle in Englisch sind. Ein Mischmasch ist nur verwirrend und zwar auch für einem selbst.

Übrigens so am Rande:
Weiss das einer eigentlich genauer, ob nun ä, ö und ü in Bezeichner erlaubt sind? Mir geht es dabei vor allem um Kapitel 2.10 Identifiers Absatz 1.

An identifier is an arbitrarily long sequence of letters and digits. Each universal-character-name in an identifier shall designate a character whose encoding in ISO 10646 falls into one of the ranges specified in Annex E. Upper- and lower-case letters are different. All characters are significant.

Das liest sich irgendwie, als wären ä, ö und ü erlaubt.

Grüssli

nachtfeuer

Ich denke auch, das kann keine Geschmacks oder Stiel...(oder Steil?) - Frage sein, ob man Bezeichnungen auf deutsch oder englisch wählt.

Der Mehrheit fehlt es einfach an ganz allgemein an Verständnis für grammatikalische Fragen oder grammatikalische Zusammenhänge.

Warum sonst werden wir von beknaktem Beamtendeutsch oder englisch geschriebenen Aufsätzen für die örtliche Häkelgruppe genervt? - Oder von zweifelhaften Unterscheidungen wie 'Daten' und 'Code' oder noch schlimmer noch, .data vs .text oder von absurden Codierbefehlen?

Man muss unterscheiden können: Bei Programmiergruppen muss man sich vielleicht sowieso auf einen Standard einigen, für Demonstrationszwecke, auch für Anfänger, in einem deutschen Forum, sind deutsche Bezeichner hilfreich, für Endversionen für Internetdownloads mit Sourcecode ist englisch sinnvoll, die Democodes für die Demoszene muss wenigstens ich selber wieder lesen können (falls überhauptnochmal)(nix open source), ich würde dann für mich also eher deutsche Bezeichner wählen.

Alles auf Okzitanisch. Ist doch klar.

sprachpurist schrieb:

Aber das hat mich gerade auf die Idee gebracht, deutsche Ausdrücke mit den englischen zu vergleichen:

struct   plan
class    bund
char     stab
int      zahl
short    kurz
long     lang
unsigned nat
include  hol
return   wirf

pointer  zeiger
array    feld
string   kette
vector   liste
list     knüpfe
node     glied
stream   strom
map      kartei

string sollte mit Unterhose ersetzt werden.

Im Prinzip ist das einzige Argument für Deutsch, dass man Englisch nicht richtig kann.

Marc++us

Dravere schrieb:

Ich bin jedenfalls grundsätzlich für Englisch.

Ich stelle diese Forderung nach Grundsätzlichkeit grundsätzlich in Abrede.

Ja, in vielen Programmteilen ist das ok, weil der Programmierer auch keinen großen Schaden anrichtet wenn er semantisch printData mit showData verwechselt.

Aber wenn die Firma nun eine Software für die Steuerung von Rangierbahnhöfen für die Deutsche Bahn schreibt, diese Software wird vom Eisenbahnbundesamt zertifiziert und nie außerhalb von Deutschland eingesetzt. Ist es dann sinnvoll, die Begriffe Englisch zu benennen? Ähnliche Fälle gibt es in der individuellen Softwareentwicklung viele. Beim Kunden gab es zuvor eine jahrelange Begriffsbildung mit deutschen Begriffen, eine Überführung in Englisch schafft nicht mehr Klarheit, sondern verschlechtert die Produktqualität. Oder diskutiert Ihr nie mal ein Ablaufdiagramm mit einem Kunden? Wenn nun die Begriffe anders heißen als beim Kunden, erscheint das jemandem sinnvoll?

Bei einem Hotelreservierungssystem ist Englisch dagegen kein Problem, der Käufer will sicherlich das System breiter ausrollen und es gibt einen englischen Glossar der Begriffe.

Und ich stelle noch eine häufig zu hörende Argumentation eines Automatismus in Abrede: Doku in IT ist sowieso immer Englisch, dann muß der Programmierer das verstehen und kann auch in Englisch schreiben.

Was ist das für eine Kausalität? Weil jemand englische Dokus LESEN kann, kann er englische abgekürzte 2/3-Wort-Kurzbegriffe SCHREIBEN? :xmas2:

elise

Marc++us schrieb:

Ich stelle diese Forderung nach Grundsätzlichkeit grundsätzlich in Abrede.

*zustimm*, vor allem in blickrichtung kommunikation mit dem kunden und darüber hinaus einsatzbereich...

im übrigen sträube ich mich ebenso von vornherein gegen "grundsätzliches", mit dem tenor einer "regel".

:xmas1:

Marc++us schrieb:

Aber wenn die Firma nun eine Software für die Steuerung von Rangierbahnhöfen für die Deutsche Bahn schreibt, diese Software wird vom Eisenbahnbundesamt zertifiziert und nie außerhalb von Deutschland eingesetzt. Ist es dann sinnvoll, die Begriffe Englisch zu benennen?

Ja, dann kann man auch was im Ausland entwickeln lassen.

Ähnliche Fälle gibt es in der individuellen Softwareentwicklung viele. Beim Kunden gab es zuvor eine jahrelange Begriffsbildung mit deutschen Begriffen, eine Überführung in Englisch schafft nicht mehr Klarheit, sondern verschlechtert die Produktqualität. Oder diskutiert Ihr nie mal ein Ablaufdiagramm mit einem Kunden? Wenn nun die Begriffe anders heißen als beim Kunden, erscheint das jemandem sinnvoll?

Was man dem Kunden zeigt muss ja nicht wortwörtlich in den Code. Bei irgendwelchen Eigennamen für die es keine englische Bezeichnung gibt, kann man die deutsche Bezeichnung verwenden, aber sonst alles englisch.

fenster.close()
if drueckknopf.getState() == PRESSED

sieht doch nur dämlich aus.

Dravere

Marc++us schrieb:

Ich stelle diese Forderung nach Grundsätzlichkeit grundsätzlich in Abrede.

Klingt irgendwie nach einem Widerspruch in sich selbst

Marc++us schrieb:

Ja, in vielen Programmteilen ist das ok, weil der Programmierer auch keinen großen Schaden anrichtet wenn er semantisch printData mit showData verwechselt.

Halte ich persönlich bereits für ein Problem, wenn dies in einer Schnittstelle passiert.

Marc++us schrieb:

Aber wenn die Firma nun eine Software für die Steuerung von Rangierbahnhöfen für die Deutsche Bahn schreibt, diese Software wird vom Eisenbahnbundesamt zertifiziert und nie außerhalb von Deutschland eingesetzt.

Mich stört ein wenig dieses "nie". Es gibt so viele Projekte, wo gesagt wurde, dass man es nur in diesem Bereich einsetzen wird und nie ausserhalb und am Ende kam es anders raus. Und dann hast du ein riesen Problem und kannst die Software geradezu neu schreiben.

Rangierbahnhof Software erinnert mich jetzt gerade an Simutrans. Das Beispiel stimmt zwar nicht überein, da es ein OpenSource Spiel ist, aber es ist so ein Fall. Das Spiel wurde auf Deutsch entwickelt und jetzt wo es plötzlich international wird und entsprechende Unterstützung bekommt, mussten sie die Richtlinien ändern. Jetzt haben sie erst recht ein Durcheinander im Code und müssen mühsam immer wie mehr übersetzen. Sieht aktuell schrecklich aus. Da schaltet es einem regelrecht ab, wenn man den Code probiert zu lesen.

Marc++us schrieb:

Ist es dann sinnvoll, die Begriffe Englisch zu benennen? Ähnliche Fälle gibt es in der individuellen Softwareentwicklung viele. Beim Kunden gab es zuvor eine jahrelange Begriffsbildung mit deutschen Begriffen, eine Überführung in Englisch schafft nicht mehr Klarheit, sondern verschlechtert die Produktqualität. Oder diskutiert Ihr nie mal ein Ablaufdiagramm mit einem Kunden? Wenn nun die Begriffe anders heißen als beim Kunden, erscheint das jemandem sinnvoll?

Ich stimme dir zu, dass dies ein Problem sein kann. Die Kommunikation mit dem Kunde kann unter Umständen von deutschen Begriffen profitieren. Aber die Qualität des Codes wird ganz sicher darunter leiden. Im allgemeinen verwendet man für jedes Projekt heutzutage irgendwelche Bibliotheken, seien es nur die Standardbibliotheken. Da ist es unweigerlich, dass du ein übles Mischmasch im Code bekommst. Und das hilft dann beim Verständnis auch überhaupt nicht.
Wenn man Deutsch und Englisch vermischt, dann fangen erst recht viele an, die Englischen Ausdrücke falsch zu interpretieren. Dann bekommst du ein völliges durcheinander was die Begriffe betrifft. Es ist sinnvoll einheitlich zu bleiben.

Bei der Kommunikation mit dem Kunden muss daher eine Zwischenschicht rein. Falls der Kunde Mühe mit den englischen Begriffen hat, muss halt ein Übersetzungskatalog her.

Marc++us schrieb:

Und ich stelle noch eine häufig zu hörende Argumentation eines Automatismus in Abrede: Doku in IT ist sowieso immer Englisch, dann muß der Programmierer das verstehen und kann auch in Englisch schreiben.

Was ist das für eine Kausalität? Weil jemand englische Dokus LESEN kann, kann er englische abgekürzte 2/3-Wort-Kurzbegriffe SCHREIBEN? :xmas2:

Naja, wenn jemand eine Sprache lernen will, empfiehlt man ihm immer, dass er zuerst Bücher in der Sprache lesen und danach in der Sprache sprechen soll. Durch das Lesen kann man definitiv eine Gefühl für die Sprache entwickeln. Aber grundsätzlich hast du natürlich schon recht, dass man dies nicht einfach so annehmen darf. Zwischen Lesen und Schreiben ist doch nochmals ein gewisser Unterschied.

elise schrieb:

im übrigen sträube ich mich ebenso von vornherein gegen "grundsätzliches", mit dem tenor einer "regel".

Ich habe es jetzt eher als eine Richtlinie gemeint. Allerdings sind mir bisher nur sehr wenige Ausnahmen über den Weg gelaufen.

Grüssli

Wenn man eine Software speziell fuer den deutschen Markt schreibt mit viel Fachterminologie (z.B. ne Verwaltungssofware fuer ne Komune, Stadt. Oder Steuersoftware etc.), dann machen deutsche Bezeichner mehr Sinn, weil diese extremen Fachterminologien der Behoerden/Steuerwelt etc. nahezu nicht uebersetzbar sind.

Meine Meinung deswegen: In der Regel Englisch, in Spezialfaellen Deutsch.

Marc++us

Dravere schrieb:

Mich stört ein wenig dieses "nie". Es gibt so viele Projekte, wo gesagt wurde, dass man es nur in diesem Bereich einsetzen wird und nie ausserhalb und am Ende kam es anders raus. Und dann hast du ein riesen Problem und kannst die Software geradezu neu schreiben.

... es gab aber mehr Projekte, bei denen man am Anfang nicht nur für die eine geplante und verkaufte Anwendung entwickelte, sondern für weitere denkbare Einsätze, wodurch die Software extrem komplex und weitschweifig wurde - mit Zeitüberschreitung, Budgetüberschreitung, und evtl. sogar Einstellung des Projekts.

Es ist zwar technisch reizvoll die Eisenbahnsoftware generisch so auszulegen, daß sie auch Fluglinien bedienen kann, aber es ist auch gleichzeitig ein guter Weg das Projekt in den Untergang zu treiben.

Dieser Pfad, zur dunklen Seite er führt.

Daß es auf irgendeiner Ebene dann mal einen Sprachenmix zwischen User-Domain und Bibliotheken gibt ist eben so... man kann ja auch den Glossar durch simples Mapping von Klassen, Objekten, Tabellen, etc, technisch realisieren.

Ich würde aber nie empfehlen mittels Glossar mit dem Kunden zu kommunizieren. Es ist ein erheblicher Vorteil, wenn man als Dienstleister die gleiche (natürliche) Sprache spricht wie der Kunde, warum sollte man diesen (Wettbewerbs-)Vorteil leichtfertig aufgeben, nur um ein rein intern-organisatorisch-schönheitswettbewerbstechnisches Regelwerk einzuhalten? Da wackelt dann der Schwanz mit dem Hund.

Sebastian Meier

+1 für Fachbegriffe in Deutsch.

Habe lange Bankensoftware entwickelt und denke es ist sehr wichtig, dass Entwickler und Kunden die gleiche Sprache sprechen. Beispielsweise hat bei uns mal ein Entwickler das Businessobjekt für Umsätze "Turnover" genannt. Ich weiß bis heute nicht, ob das überhaupt der passende Begriff ist. Jedenfalls hat sich das durch die ganze Anwendung gezogen und im morgendlichen Scrum-Meeting haben wir dann über "getTurnover" und das "TurnoverPanel" geredet. Aber wenn zehn Minuten später der Kunde anrief, mussten wir auf "Umsatz" umschalten. Dazu kam, dass eine andere Abteilung sich für "Transaction" entschieden hatte , so dass sogar unsere Abteilungen begrifflich nicht auf einer Wellenlänge waren.

Und "Umsatz" ist noch einfach. Ich will gar nicht erst mit "Dispokredit-Linie" oder "Abwicklungskunde" anfangen.

hustbaer

@Sebastian Meier & Marc++us

Ich verstehe eure Argumentation vollkommen und will auch gar nicht widersprechen.

Hätte aber ein paar Fragen...

Wie macht ihr es dann mit deutschen Fachbegriffen?
Alles auf Englisch bis auf die Fachbegriffe? Also "GetUmsatzView" und "CreateDispokreditBerechnungImpl"?

Und habt ihr einen guten Richtwert/Faustregel wo man in solchen Fällen die Grenze ziehen sollte?

Und ... führt ihr - mehr oder weniger - verbindliche Listen von Fachbegriffen? Sonst passiert ja sowieso wieder das was Du (Sebastian) beschrieben hast: einer sagt so, der andere anders. Deutsche Fachbegriffe zu verwenden schützt ja nicht gegen z.B. Kellerspeicher vs. Stapelspeicher.

----

Ich selbst hatte noch nie ein Projekt wo viele derartige Fachbegriffe vorgekommen wären, worüber ich auch sehr froh bin
Ich meine nur: wenn es KEINEN derart guten Grund gibt Dinge deutsch zu benennen, dann finde ich sollte man es auch bleiben lassen. Nur "ja weil ich mich auf Deutsch leichter tue" ist für mich eben kein ausreichender Grund.

Sebastian Meier: Volle Zustimmung. Wichtig ist am Ende, dass jemand, der in den Code kuckt, sofort versteht, worum es grob geht. Wenn dabei Denglisch rauskommt, dann ist das halt so. Man muss es nicht mögen, aber es ist besser, als "Abgeltungsteuer" im Code durch eine hausgemachte Übersetzung zu ersetzen, die keiner kennt oder versteht.

hustbaer: Häufig stellt sich die Frage überhaupt nicht, wenn man nicht in jeden zweiten Funktionsnamen "set" oder "get" schreiben will. Dort, wo es mal vorkommt, verhalte ich mich in der Regel so, wie ich vermute, dass es auch ein englischsprachiger Mensch, der mit ausländischen Sachverhalten zu tun hat, täte - ich lasse die nicht übersetzbaren Teile unübersetzt. Bei deinen Beispielen liefe das wahrscheinlich "UmsatzView" und "CreateDispoKreditCalculationImpl" oder etwas vergleichbares hinaus. Obwohl "Umsatz" vermutlich mit etwas Nachdenken auch sinnvoll übersetzbar wäre; da bin ich leidenschaftslos.

Letztendlich ist das aber natürlich ein großes Stück weit einfach Geschmackssache, und über Geschmack lässt sich bekanntlich lange und ergebnislos streiten.

Zum Programmieren in Landessprachen generell noch eins - ich hatte vor einiger Zeit eine sehr interessante Diskussion mit einem portugiesischsprachigen Programmierer, der höchst unerfreut darüber war, dass er in Quellcode auf das basic source character set beschränkt war - im konkreten Fall, dass er "ñ" nicht benutzen konnte. So stand überall in seinem Code, wo er "Jahre" meinte, "Anus". Da haben wir als Deutsche es mit drei Umlauten und ß doch noch richtig gut und einfach.

EOP

seldon schrieb:

Zum Programmieren in Landessprachen generell noch eins - ich hatte vor einiger Zeit eine sehr interessante Diskussion mit einem portugiesischsprachigen Programmierer, der höchst unerfreut darüber war, dass er in Quellcode auf das basic source character set beschränkt war - im konkreten Fall, dass er "ñ" nicht benutzen konnte. So stand überall in seinem Code, wo er "Jahre" meinte, "Anus".

LOL - wenigtens etwas Lustiges in diesem thread (Faden :p).

Dravere

Marc++us schrieb:

Es ist zwar technisch reizvoll die Eisenbahnsoftware generisch so auszulegen, daß sie auch Fluglinien bedienen kann, aber es ist auch gleichzeitig ein guter Weg das Projekt in den Untergang zu treiben.

Bitte bleib im Kontext. Es ging um die Begriffe und Kunden. Mir ging es darum, dass ein französischer Bahnbetreiber von der Software etwas mitbekommen hat. Er ist sich das bei der DB anschauen gegangen und war begeistert. Nun fragt er dich an, ob er die Software auch für seinen Rangierbahnhof haben kann. Es gibt schliesslich gewisse europäische Standards im Schienenverkehr, wodurch sowas durchaus möglich wäre. Und nun? Deine ganze Software ist in Deutsch und du hast plötzlich einen französisch sprechenden Kunden.

Wobei ich sagen muss, dass bei Begriffen wie "Dispokredit-Linie" oder "Abwicklungskunde" man sich schon berechtigt fragen sollte, ob man diese Begriffe sinnvoll übersetzen kann. Allerdings fragt sich auch, ob solche Begriffe wirklich 1:1 als Bezeichner in der Software vorkommen werden. Hängt natürlich auch etwas von der Anwendung ab. Aber das würde nichts daran ändern, dass ich grundsätzlich zuerst für Englisch wäre. Ausnahmen habe ich ja nicht ausgeschlossen.

Früher hat man Wert auf die technischen Aspekte gelegt und die Kommunikation mit dem Kunden vernachlässigt. Heute legt man Wert auf die Kommunikation mit dem Kunden und fängt meiner Meinung nach an, die internen Teile zu vernachlässigen, bis sich die Techniker untereinander nicht mehr verstehen. Ist beides keine gute Idee.

Wenn jemand zu mir kommt und meint, dass er eine Datenreihe im Keller angelegt hat, dann ist mein erster Gedanke sicher nicht bei einem Array auf dem Stack

Grüssli