Manuelles Ändern von Encoding comitten

[tuxandra]

Liebe Eclipse- und Encoding-Gurus
Ich habe folgendes Problem:
die Javadateien meines Projekts waren fälschlicherweise in Iso-8859-1 codiert und wurden in Eclipse natürlich dadurch auch nur mit diesem Encoding korrekt angezeigt. Ich habe dann manuell mit dem Befehl "recode" alle Dateien auf utf-8 gesetzt und im Eclipse das Projekt (und alle Dateien) ebenfalls. So weit so gut, alles wird korrekt angezeigt. Der Haken an der Sache: diese Umkodierung wird nicht als Änderung der Datei angesehen und lässt sich daher nicht committen, sprich, wenn ich das Projekt auf einem anderen Computer öffne, sind die Dateien dort nach wie vor in Iso-8859-1 kodiert.

Gibt es eine Möglichkeit, das aktuelle Encoding einer Klasse/Datei zu committen??

Vielen Dank für eure Antworten!

 

[Wildcard]

Wenn du die einfache Regel befolgst, dass Umlaute im Quellcode nichts zu suchen haben, dürfte das Encoding keine Rolle spielen.

 

[byte]

Du verwendest also nie Umlaute in Strings oder Kommentaren? ???:L

 

[Wildcard]

Du verwendest also nie Umlaute in Strings oder Kommentaren? ???:L

Nein, Strings sind natürlich Externalisiert und Kommentare Englisch.

 

[tfa]

Die Dateien ändern sich ja auch nicht. Aber wenn das Encoding in den Projekteigenschaften umgestellt wurde, sollte man das auch comitten können. Reicht das nicht?

PS: Es spricht absolut nichts gegen Sonderzeichen im Quelltext. Besonders in Java mit seiner Unicode-Unterstützung. Es sei denn, man stanzt seine Lochkarten noch in EBCDIC.

 

[byte]

Du verwendest also nie Umlaute in Strings oder Kommentaren? ???:L

Nein, Strings sind natürlich Externalisiert und Kommentare Englisch.

Die Praxis sieht häufig anders aus, wenn ein Projekt von vielen Entwicklern bearbeitet wird, die auch noch von Zeit zu Zeit wechseln. Im übrigen schreibe ich Kommentare auch für gewöhnlich in deutsch. Sehe keinen Grund für englische Kommentare, wenn das Projekt eh nur aus deutschen Entwicklern besteht.

Häufig werden auch Klassen, Methoden und Member auf deutsch benannt. Das ist sinnvoll, wenn man eine Fachdomäne objektorientiert abbilden möchte. Einerseits gibt es für viele domänenspezifische Begriffe in der Wirtschaft gar keine allgemeingültige englische Übersetzung. Und andererseits vereinfacht das die Kommunikation mit dem Fachbereich erheblich. Du kannst den Kunden durchaus mal ein (vereinfachtes) Klassendiagramm zeigen. Wenn die Klassen in der Sprache ihrer Domäne benannt sind, werden sie die Zusammenhänge verstehen. Nennst Du sie hingegen um (indem Du ins englische übersetzt), blickt keiner mehr durch.

 

[Wildcard]

@tfa
Wenn du Die Dateien ausserhald des Workspaces mit recode verändert hast, muss du das Eclipse auch mitteilen. Versuch ein refresh auf allen Projektem, ein clean und wenn alles nichts hilft, das löschen der .metadata.

@byto

Die Praxis sieht häufig anders aus, wenn ein Projekt von vielen Entwicklern bearbeitet wird, die auch noch von Zeit zu Zeit wechseln

Sollte man nicht gerade dann Englisch als den kleinsten gemeinsamen Nenner, sozusagen als Lingua Franka verwenden? Der nächste Kollege der ins Team aufrückt wird Chinese, Inder, Franzose oder Nigerianer sein.

 

[byte]

@byto

Die Praxis sieht häufig anders aus, wenn ein Projekt von vielen Entwicklern bearbeitet wird, die auch noch von Zeit zu Zeit wechseln

Sollte man nicht gerade dann Englisch als den kleinsten gemeinsamen Nenner, sozusagen als Lingua Franka verwenden? Der nächste Kollege der ins Team aufrückt wird Chinese, Inder, Franzose oder Nigerianer sein.

Wir leben zwar im Zeitalter der Globalisierung aber ich habe sowas bisher noch nicht erlebt. Prinzipiell ist es doch immernoch so, dass von Mitarbeitern in Deutschland auch erwartet wird, dass sie der deutschen Sprache mächtig sind. Bin derzeit beim Autobauer mit den zwei großen Buchstaben tätig und dort ist Konzernsprache Deutsch, auch wenns zig Werke im Ausland gibt. Wir haben auch einige Entwickler im Team, die nicht deutscher Herkunft sind, trotzdem aber alle deutsch können.

Ich sehe das mit den englischen Kommentaren eher gespalten. Prinzipiell hast Du natürlich recht, dass englische Kommentare sinnvoll sind. Andererseits ist es ja usus, dass viele Entwickler eher zu wenig als zu viel den Code kommentieren. Wenn sie das nun auch noch in Englisch tun müssen (was die meisten wohl schlechter können als deutsch), hätte das wahrscheinlich zweierlei Auswirkungen: Erstens wird generell noch weniger kommentiert als sowieso schon und zweitens werden die englischen Kommentare auch noch schlechte verständlich.

Dann doch lieber auf deutsch, zumindest wenn die Sprache Nr. 1 im Team Deutsch ist.

 

[Wildcard]

Letztlich ist es eine Team/Firmen Entscheidung. Wenn ihr euch sicher seid nie ein internationales Team zu werden und/oder den Quellcode veröffentlichen wollt, soll mir recht sein.
Ich hätte allerdings auch wenig Lust mich durch einen Quellcode mit zB chinesischen oder polnischen Methoden und Kommentaren zu wühlen und entsetzt festzustellen, dass ich die Methoden mit meinem Tastaturlayout nichtmal aufrufen kann ohne auf Copy/Paste zurückgreifen zu müssen

 

[byte]

Jo, da hätte wohl keiner Lust zu. Ich habe jetzt auch von dem Standpunkt der Entwicklung von Individualsoftware gesprochen. Wenn man Software wirklich auf dem Markt verkaufen will und international tätig ist, dann ist es bestimmt sinnvoll, das anders anzugehen. Wenn Du hingegen eine zugeschnittene Software für Unternehmen X in Deutschland entwickelst, ist das imo etwas anderes.

 

[maki]

Hab mich schon mit Quelltext aus der Tschechei rumgeschlagen... schlecht geschriebene englische Kommentare sind besser als gute aber für mich nicht verständliche tschechische Kommentare...

Persönlich schreibe ich alles in englisch, der Kunde hat englisch als konzernsprache (auch wenn die Franzosen sich nicht wirklich daran halten), von daher kein Problem.

Bin auch stark am überlegen ob unsere Dokuwiki Einträge nicht auch nur auf englisch geschrieben werden sollten.

 

[Wildcard]

Persönlich schreibe ich alles in englisch, der Kunde hat englisch als konzernsprache (auch wenn die Franzosen sich nicht wirklich daran halten), von daher kein Problem.

Bin auch stark am überlegen ob unsere Dokuwiki Einträge nicht auch nur auf englisch geschrieben werden sollten.

Sehe ich genauso. Softwareentwicklung ist der falsche Ort um die deutsche Sprache vor dem Aussterben bewahren zu wollen.

 

[maki]

Softwareentwicklung ist der falsche Ort um die deutsche Sprache vor dem Aussterben bewahren zu wollen.

Ja, speziell in der SW Entwicklung, aber in der IT allgemein auch.

Vor allem klingen die englischen Begriffe um einiges "flüssiger" wenn es um SW Entwicklung geht.

"KnotenBesucher" ist nicht wirklich deutsch und sehr unüblich, googeln danach bringt gerade mal 9 Ergebnisse, bei "NodeVisitor" ist das schon anders.

 

[byte]

"KnotenBesucher" ist nicht wirklich deutsch und sehr unüblich, googeln danach bringt gerade mal 9 Ergebnisse, bei "NodeVisitor" ist das schon anders.

Sehe ich genauso, wenns um IT-technische Begriffe geht. Sobald es aber um das Domänenmodell geht, ist es imo wesentlicher sinnvoller, bei der Fachsprache zu bleiben, die der Kunde benutzt. Häufig gibt es Fachbegriffe, die Du gar nicht übersetzen kannst. Oder es sind einfach Begriffe, die in einem anderen Kontext eine ganz andere Bedeutung haben (Konzern A versteht unter dem Begriff etwas ganz anderes als Konzern B, obwohl es die gleiche Branche ist). Wenn Du diese Fachbegriffe im Domänenmodell übersetzt oder veränderst, dann musst Du jedes Mal nachdenken, wenn Du mit dem Fachbereich sprichst ("Was war nochmal Kostenstelle in meinem Objektmodell?"). Das geht vielleicht noch so lange gut, wie Du nur über eigenen Code sprichst. Spätestens wenn Du aber Code wartest, den jemand anders geschrieben hast, wird es echt böse.
Das Domänenmodell ist ein Modell der Wirklichkeit, demnach sollte es auch die Begriffe der Wirklichkeit benutzen, weil Sprache nun mal alles andere als Eindeutig ist.

 

[Wildcard]

Und wie überträgst du das auf die Bean Conventions? Sträuben sich dir nicht die Haare wenn du eine isKostenStelleVerfuegbar oder getKostenStelle hast?

 

[byte]

Und wie überträgst du das auf die Bean Conventions? Sträuben sich dir nicht die Haare wenn du eine isKostenStelleVerfuegbar oder getKostenStelle hast?

Früher hab ich auch die Meinung vertreten, dass alles auf Englisch sein muss. Dementsprechend haben sich mir in der Tat anfangs die Haare gesträubt, wenn ich sowas wie getKostenstelle() gelesen habe. Mittlerweile sehe ich es aus o.g. Punkten jedoch anders.

Es gibt ein gutes Buch zu diesem Thema, wo es u.a. darum geht:
http://www.amazon.de/Domain-Driven-...ie=UTF8&s=books-intl-de&qid=1203694311&sr=8-1

“Einige Dich auf eine Sprache!” - das ist das eigentliche Motto. Domain entspricht hierbei der Fachlichkeit bzw. dem Fachwissen, und zwar explizit nicht der technischen Sicht. Domain Driven heißt hierbei Orientierung am Anwender, also wird alles von der fachlichen Ebene getrieben, nicht von der technischen Umsetzung.

Die Modelle bzw. der Code sollte die Sprache der Fachanwender wiederspiegeln, damit die Anwender direkt mit den Entwicklern sprechen können und ein gemeinsames Verständnis der Begriffe vorhanden ist, auch im Hinblick auf spätere Änderungen und Fluktuationen.

Orientiere Dich in der technischen Umsetzung immer an der Unterstützung der fachlichen Anforderungen, und Deine Codebasis wird stabiler und einfacher sein, sowohl in der Entwicklung als auch in der Wartung, selbst wenn die Anwendung skaliert.

 

[Wildcard]

“Einige Dich auf eine Sprache!”

Sehe ich genauso. Nur bin ich der Meinung das sie englisch sein sollte (es sei denn man kann sich sicher sein ein auch in Zukunft ein rein nationales Team zu haben).
Ich denke ein Entwickler sollte in der Lage sein anhand einer Übersetzungstabelle trotz englischer Begrifflichkeiten im Code den Brückenschlag zur DSL zu schaffen.
Just my 2 cents...

 

[tfa]

Ich denke ein Entwickler sollte in der Lage sein anhand einer Übersetzungstabelle trotz englischer Begrifflichkeiten im Code den Brückenschlag zur DSL zu schaffen.

Man muss eben abwägen zwischen Codeästhetik und Pragmatismus. Pragmatismus ist meiner Meinung nach weitaus wichtiger. In meinem aktuellen Projekt gibt es z.B. so eine Übersetzungstabelle nicht. Von vielen Fachbegriffen gibt es keine offizielle englische Übersetzung, nicht mal eine offensichtliche. Warum sollte man sich jetzt krampfhaft eine ausdenken, nur damit es im Quelltext englisch ist? Da macht man sich nur das Leben unnötig schwer. Am Ende reden alle aneinander vorbei und Kunde versteh gar nichts mehr, wenn man seine Vokabeln nicht gelernt hat.
Vielleicht bin auch nur in einem extremen Projekt, was das angeht. Manchmal versteh ich sogar die deutschen Begriffe nicht...

 

[byte]

Nehmen wir mal das Beispiel "Kostenstelle" (ein Begriff, der im BWL-Kontext sehr häufig vorkommt). Leo spuckt folgende Übersetzungen aus:
- accounts
- burden center
- cost center
- cost unit

In der Praxis würden wahrscheinlich unterschiedliche Entwickler in ihren Komponenten unterschiedliche Übersetzungen wählen und das Domain Model wäre sprachlich nicht mehr konsistent. Gehen wir aber mal vom (häufig utopischen) Idealfall aus, dass es eine Übersetzungstabelle gibt, wo die gültigen Übersetzungen aller Fachbegriffe drin stehen.
Nun ruft der Kunde an und sagt "die Kostenstelle wird falsch berechnet". Nun habe ich erstmal Mehrarbeit, indem ich nachschlagen muss, wie nun diese Kostenstelle im Domain Model heisst. Das ist es mir wirklich nicht wert, wenn der einzige Gain kosmetischer Natur ist.