Bezeichnungen in deutsch oder englisch?

wx++

Wenn die relevante Chance besteht, dass der Code von nicht-deutschsprachigen Menschen gelesen wird englisch, ansonsten kannst du es dir aussuchen.

hustbaer

Anderes Argument für Englisch: die ganzen Keywords und Informatik-Fachbegriffe sind in Englisch. Und mir kommt immer das Kotzen, wenn ich Code lese, wo sich deutsche und englische Bezeichnungen vermischen. Was sogut wie immer passiert, wenn man anfängt deutsche Variablen/Klassennamen zu verwenden.

Kurz: wer Englisch kann sollte Englisch verwenden, und wer kein Englisch kann sollte Englisch lernen.

Englisch

Weil, ich damit meiner Meinung nach kurze aussagekräftige Namen hin bekomme. Das ist im Deutschen schon allein wegen der Umlaute schwierig.

Andere Menschen sprechen alle Englisch

Das halte ich für ein Gerücht. Ich hab auch mal was über die wirklich am meisten verbreitete Sprache gehört. Diese spreche ich aber nicht, deswegen kann man auch da nicht von allen ausgehen.
Was aber zutreffen wird ist, dass alle Leute die genügend Bildung besitzen Quelltexte lesen zu können mit hoher Wahrscheinlichkeit, mehr oder weniger gut, auch Englisch sprechen können.
Auch hat Englisch einen anderen Vorteil, es dient als Zwischensprache für viele Übersetzer.

Incocnito

Das halte ich für ein Gerücht. Ich hab auch mal was über die wirklich am meisten verbreitete Sprache gehört. Diese spreche ich aber nicht, deswegen kann man auch da nicht von allen ausgehen.

Ist dann wahrscheinlich Standard-Chinesisch. Ich meine, in Asien leben 4.3 Milliarden Menschen. Wenn dort ca 50% eine Sprache sprechen, kann man sich die Zahl ja vorstellen. Aber da chinesisch schwer zu erlernen ist, und Englisch an so gut wie allen Schulen unterrichtet wird (im gegensatz zu chinesisch), ist (auch für chinesen) oft Englisch als internationale Sprache die bessere Wahl.

Was die Variablennamen angeht, kommt einfach drauf an, ob den Quellcode noch jemand anders lesen könnte. Und wenn ja, dann höchstwahrscheinlich auch nur von anderen Deutschen. Wenn er allerdings (wahrscheinlich) auch von Ausländern gelesen werden könnte, nimm einfach Englisch. Nichts, worüber man lange nachdenken sollte. Suchs dir einfach aus.

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.