Umlaute in Namen von Funktionen und Variablen

[TM6]

Ich habe durch Zufall festgestellt, dass man in den Namen von Funktionen oder Variablen auch Umlaute nutzen könnte.
Seit wann ist denn das der Fall?
Was spricht eigentlich dagegen?

Das Thema Abwärtskompatibilität mal ausgenommen.

[dummzeuch]

Zitat von TM6:

Ich habe durch Zufall festgestellt, dass man in den Namen von Funktionen oder Variablen auch Umlaute nutzen könnte.
Seit wann ist denn das der Fall?

Soweit ich weiss, seit mindestens Delphi 2009 (Unicode), aber es würde mich nicht wundern, wenn es schon seit der "neuen" IDE (Delphi 8) ginge.

Zitat:

Was spricht eigentlich dagegen?

Dagegen spricht, dass z.B. deutsche Umlaute nur in wenigen Ländern bekannt/gebräuchlich sind. Wenn ein Amerikaner Sourcecode mit Identifiern mit solchen Zeichen sieht, versteht er sie nicht nur nicht, er hat generell Probleme sie zu lesen. Um das nachzuvollziehen, stell Dir mal Sourcecode mit z.B. dem dänischen å (bolle-A) oder dem ӕ (AE Ligatur) vor. Das wird ganz schnell unübersichtlich.

[jaenicke]

Du kannst auch chinesische Zeichen usw. verwenden, aber sinnvoller ist sich an englische Bezeichner zu halten. Das ist nun einmal die Sprache der Softwareentwicklung...
Und sobald ein eigener Quelltext auch mal an andere Entwickler geht, ist es ungewohnt bis unlesbar, wenn da etwas anderes als Englisch verwendet wird, je nachdem ob derjenige die Sprache spricht.

Und wenn man nur englische Bezeichner verwendet, stellt sich die Frage nach Unicodezeichen usw. gar nicht.

Heute sollte es aber keine technischen Probleme mehr damit geben.

[Redeemer]

Zitat von TM6:

Ich habe durch Zufall festgestellt, dass man in den Namen von Funktionen oder Variablen auch Umlaute nutzen könnte.
Seit wann ist denn das der Fall?

D2005 glaube ich.

[himitsu]

Jupp, seit "genau Delphi 2009", als Delphi auf Unicode (die RTTI auf UTF-8, also eigentlich hat sich intern, an den RTTI-Strukturen, garnichts geändert) umgestellt wurde,
und das betrifft Alles, also auch Unitnamen, Typen, Variablen, Konstanten und die Komponenten im FormDesigner.

Vom Lesen her sind englische Bezeichner besser optimaler, da sie sich "schöner" in die anderen englischen Bezeichner einpassen, also die steuerwörter ala BEGIN/FOR/WHILE/usw. und auch die Namen der Typen/Funktionen/Klassen von RTL/VCL/... und von Fremdkomponenten.

Ich hatte mal EINEN Versuch gemacht ALLES auf Deutsch zu schreiben, aber da würde ich nur kirre von.
In anderen Sprachen (Chinesisch und Co.) kann man super kurze Programme schreiben, wenn man für jeden Bezeichner nur noch 1 Zeichen braucht.


Aber wer gern seine Funktionen/Variablen/Komponenten/... deutsch, russisch oder chinesisch benennen will, bekommt keine Probleme.
Selbst Unicode-Smilies gehen ... sind aber kaum zu erkennen, bei der kleinen Schrift und in schwarzweiß. (praktisch fast Alles, außer Punctuation und ControlChars)

Delphi-Quellcode:

const
  😀 = 'lachen';
  😁 = 'grinsen';
  😂 = 'totlachen';
  █ = 'schwarz';
  ▒ = 'grau';
  ░ = 'hellgrau';
  müll = 'fgsae4g478q49tsdga154gra5';
  ✓ = True;
  ✗ = False;
  ✔ = True;
  ✖ = False;

test := ✔;
if test then ...

[TM6]

Danke für die Infos.
Wir haben aktuell situationsbedingt englische, deutsche oder gemischte Bezeichner.
Abhängig davon, was kürzer und verständlicher ist.
Bei gemischt kommen dann aus beiden Sprachen zusammengesetzte Begriffe wie zum Beispiel
Kante_First, Kante_Last, Kante_Prev, Kante_Next vor.

Niemand würde Nächste(r) oder Naechste(r) einem kurzem und neutralem Next vorziehen.

Werde dann in Zukunft aber wohl Umlaute nutzen, da zum Beispiel
Müll
einfacher zu lesen ist als
Muell
Vor allem, wenn dann noch mehr Zeichen und eventuell auch noch mehr Umlaute ins Spiel kommen.

[Bernhard Geyer]

Zitat von TM6:

Bei gemischt kommen dann aus beiden Sprachen zusammengesetzte Begriffe wie zum Beispiel
Kante_First, Kante_Last, Kante_Prev, Kante_Next vor.

Wer ohne solche Konstanten im eigenen Code ist, möge den ersten Stein schmeißen.

Ich würde aber hier auch eher auf komplett Englisch wechseln.
Oft wirken die deutschen Begriffe ziemlich schräg und durchgehend englich ist hier besser zu lesen.
(Passt ja auch besser zu den englischen Pascal-begriffen wie for/while/...)

[freimatz]

Zitat von Bernhard Geyer:

Wer ohne solche Konstanten im eigenen Code ist, möge den ersten Stein schmeißen.

Habe gerade keine Lust einen zu suchen...
Bei uns in Firma ist das so. Code ist da alles englisch. Kommentare sind gemischt.

Bei meinem "Homeprojekt" habe ich auch gemischt. Da ist es in der Regel so dass Domänenbegriffe in deutsch sind. Allgemeine Begriffe wie next oder count sind dann eher englisch.

[Uwe Raabe]

Zitat von TM6:

Werde dann in Zukunft aber wohl Umlaute nutzen, da zum Beispiel
Müll
einfacher zu lesen ist als
Muell

Dann mach dich eventuell auf diverse Probleme mit externen Tools gefasst, die mit solchen Dingen (noch) nicht klar kommen. So mancher Parser Code für Delphi ist schon recht alt und setzt bei Bezeichnern halt immer noch reine ASCII-Zeichen voraus.

[himitsu]

Zitat von Uwe Raabe:

Dann mach dich eventuell auf diverse Probleme mit externen Tools gefasst, die mit solchen Dingen (noch) nicht klar kommen. So mancher Parser Code für Delphi ist schon recht alt und setzt bei Bezeichnern halt immer noch reine ASCII-Zeichen voraus.

Die Datei als UTF-8 gespeichert (ohne BOM, aber Delphis kann leider nur mit BOM speichern) und schon wäre das Unicode fast wie ANSI.
Also wenn nicht wirklich nur als 7-Bit ASCII sondern auch das 8. Bit erlaubt sind, da sollte es dann mit "solchen" Tools dennoch gehn.