Wie lang sollte ein Variablenname maximal sein?

Ich wollte auch nochmal meinen Senf dazugeben:
Ich habe eine eigene Konvention entwickelt, bei der im Prinzip zusammengehöriges in Höckerform* steht, Dinge, die man als Attribute auffassen kann, oder etwas näher spezifizieren, werden durch Unterstriche angeschlossen (diese haben in letzter Zeit auch zugenommen, trotz Java in der Schule).
Gekürzt wird, wenn irgendetwas subjektiv zu lange ist.
Wir sollten beispielsweise eine Liste unter Verwendung des Kompositum-Entwurfmusters implementieren.
Meine Klassen nannte ich Liste, L_Element, LE_Inhalt, LE_Abschluss, L_DTyp, Ganzzahl, Patient; ich hoffe, sie sind selbsterklärend. (LE_Inhalt sollte im Nachhinein vielleicht in LE_Daten umbenannt werden)
Das Problem mit den Temperaturen hätte ich also leicht erschlagen:
Temperatur_Celsius, wenn er oft vorkommt, vielleicht auch Temp_Celsius oder T_Celsius (aber mit hoher Wahrscheinlichkeit nicht Temperatur_C – dass sie in Celsius ist, ist ja das Wichtigste)

*(CamelCase, und ja, das habe ich mir gerade eben ausgedacht)

Shiba

Regel schrieb:

... sehe ich keinen Grund in hustbaers Beispiel so lange Variablennamen zu wählen. Klar, in dem Beispiel ging es eher um die Templategeschichte, aber ansonsten würde ich (für dieses Beispiel) wahrscheinlich statt

Nun ja es ist ein plakatives Beispiel mit einfachen Annahmen.
Bei einem Programm, das Jahre laufen soll, entwickelt und gewartet werden muss, sieht es meiner Erfahrung nach anders aus.
v ist nämlich nicht sonderlich aussagekräftig. Gibt es in anderen Funktionen noch weitere v´s oder Derivate wie v1, v0 ( oder alles was die Kombinatrik hergibt) mit unterscheudlichen Bedeutungen, dann kann das verwirren.
Problematisch ist auch, wenn das Namenssystem auf das man sich bezieht, mehrere Varianten mit einem unterschiedlichen Sachbezug zu läßt.
Hier im Beispiel ist es e_kin. Ich kenne dafür die Kürzel E und T. e_kin ist mir aus der Hydrodynamk geläufig, um die es hier wohl nicht geht.
Das heißt aber im konkreten Fall, dass der nachfolgende Programmierer die Kürzelwahl genauso verstehen muss wie der Entwickler des Programms.
In der Praxis findet man allerdings häufig, das die selbst die "Erfinder" nach einiger Zeit Probleme haben die eigenen Einzeichennamen sofort zu erklären.

:xmas2: Nur so am Rande: die Formel zur kinetischen Energie ist falsch.
Ohne Trägheit und Rotation zubeachten, sollte es heißen:
T = 1/2Mv²
oder vielleicht auch entsprechend dem Beispiel
e_kin = 1/2mv²

Von daher nehme ich lieber Namen, die den Sinn der Variablen deutlich machen.
Ausnahmen davon sind i,j,k

Shade Of Mine

[Rewind] schrieb:

knivil schrieb:

Lesbarkeit wird nicht unbedingt durch laengere Variablennamen erhoeht.

Richtig. Dafür kann aber Lesbarkeit durch zu kurze Namen stark eingeschränkt werden. Das steht für mich außer Frage.

Selbes gilt für zu lange Namen.
Siehe: http://thedailywtf.com/Articles/TalesFromTheLongMethodNameGenerator(int-maxLength).aspx

Der Name muss treffend und passend sein.
db_connection
ist zB nicht unbedingt besser als
db

und db.query() ist uU besser als connection.run_sql_query()

Aber natürlich ist connection.run_sql_query() besser als c.run()

Nur lange Namen machen die Sache nicht lesbar. Es ist die signifikanz des Namens der Zählt. Weiters gibt es Konventionen die kurze Namen ermöglichen. In Javascript werden Variablen vom Typ event einfach evt genannt. Zählvariablen heissen i und es gibt das count-Idiom in PHP das $c verwendet: for($ i=0, $c=count($ foo); $i<$ c; ++$i)
da ist $c einfach der Standardname. Ähnlich in C wenn ich zB ein strcpy mache, dann heissen die Parameter auch src und trg. In einer Liste sind die Zeiger auf die beiden Nachbarknoten pred/next und prev.

volkard

Shade Of Mine schrieb:

Ähnlich in C wenn ich zB ein strcpy mache, dann heissen die Parameter auch src und trg.

Da haste aber jetzt ein dickes Ei gelegt.
http://www.nxmnpg.com/3/strcpy

314159265358979

trg habe ich noch nie gesehen.

Aber natürlich ist connection.run_sql_query() besser als c.run()

Warum? Du hast doch davor noch behauptet, dass db_connection unter Umständen schlechter sein kann als db . Genauso kann conncetion unnötig lang sein und c vollkommen ausreichen.
Es kommt halt immer auf den Anwendungsfall an.

GoaZwerg schrieb:

Also bei i (vor allem als Zählvariable), j, k sehe ich das aber auch so wie Du.
Nur eben nicht bei etwas komplexeren Methoden.

i, j, k für Zählvariablen, ok
und was ist mit x, y, z für Fließkommazahlenhalter für diverse Berechnungen?

x, y, z wird nämlich zum Rechnen (meist als double) genauso gerne genommen, wie i, j und k zum Zählen.

snOOfy

pumuckl schrieb:

auto myKineticEnergy = mySpeed * myMass;

Die Formel für die kinetische Energie ist doch E=1/2*m*v^2. m*v ist der Impuls...

Shade Of Mine

volkard schrieb:

Shade Of Mine schrieb:

Ähnlich in C wenn ich zB ein strcpy mache, dann heissen die Parameter auch src und trg.

Da haste aber jetzt ein dickes Ei gelegt.
http://www.nxmnpg.com/3/strcpy

dst?
Na da gefällt mir mein trg für target aber besser. Ich verwende das eigentlich immer für targets -> wenn es ums Kopieren geht. Ausser bei iteratoren da ist es eher in und out.

Was mir aber an src und trg besser gefällt als in/out ist, dass sie gleich lang im Namen sind und daher optisch besser alignen

_matze

Shade Of Mine schrieb:

Was mir aber an src und trg besser gefällt als in/out ist, dass sie gleich lang im Namen sind und daher optisch besser alignen

Das gilt aber für src und dst genauso. :p

phcn.fraggle

Namenslänge schrieb:

Wie sind eure Erfahrungen diesbezüglich so.

Erstmal überlege ich mir ob es ein kürzeres Synonym gibt falls mir das Wort
zu lange erscheint, ansonsten versuche ich wenn es die Umstände nicht anders zulassen möglichst selbsterklärende und eindeutige Abkürzungen zu verwenden ( wie bspw. tmp für temporary )

Allerdings ist temperatur_celsius sehr lange und stört beim Coden, weil man so viel tippen muß.

Naja wenn es andererseits kryptisch/zu kurz wird dann unterstützt das nicht wirklich die Lesbarkeit deines Codes.

int t; // t steht für die Temperatur in Celisus

Die Variable "t" kann alles mögliche sein in meinen Augen. Wenn du stattdessen
"temperaturCelsius" verwendest dann ersparst du dir dadurch schon mal dein Code-Kommentar.

volkard

Tut mir leid. Aber das ist nicht Deine Wahl.
Destination(Zielort) ist treffender als Target(Angriffsziel).
Und es ist hundertmal üblicher.

phcn.fraggle

volkard schrieb:

Tut mir leid. Aber das ist nicht Deine Wahl.
Destination(Zielort) ist treffender als Target(Angriffsziel).
Und es ist hundertmal üblicher.

Ich hab ja auch geschrieben wenn mir das eigentliche Wort "zu lang" erscheint.
Bei deinem Beispiel ist das nicht der Fall, kann aber auf Anhieb kein besseres
Beispiel bringen.

muemmel

Hi,

Stroustrup sagte in seinem Buch "Halten sie Kommentare knackig".
Das gleiche kann man aber auch zu Variablennamen sagen.
Was nützt der beste Variablenname, wenn man ihn jedes mal wieder von vorne bis hinten durchbuchstabieren muss. Variablennamen haben dann ihre maximal sinnvolle Länge erreicht, wenn das Auge sie gerade noch als Gesamtheit erfassen kann. Wenn man das Wort sieht und aus seinem Aussehen sofort weis, das ist es, dann liest es sich flüssig. Wenn man aber Worte jedes mal aufs neue erst erschließen muss, dann ist das Gehirn mit dem Worterkennen ausgelastet und der eigentliche Inhalt geht dahinter verloren. Das Gehirn "vergisst" sozusagen, was das Wort einem sagen sollte.
Zu wenig Information ist sicher nicht gut, aber zu viel auch nicht, das wusste schon der alte Konfuzius, und er hat kein C++ gekannt.
Wie negativ eine Überflutung mit Information ist wissen am besten die Politiker, die gerne große Massen an wertfreier Information verbreiten und damit den Mangel am Wesentlichen kaschieren. Es funktioniert überall nach den gleichen Regeln, wenn das Gehirn mit zu viel Masse überfordert wird, erhöht eine weitere Zugabe den Informationsgewinn nicht, sondern verringert ihn.

So ist für alte Fortran-Programmierer i, j, k... durchaus informativer als lange Namen, weil sie sofort wissen, das ist eine einfacher Schleifenzähler...
Und wenn in einer Funktion die Temperatur berechnet werden soll und die Funktion heist berechneSchmelztemperatur oder vergleichbar, dann ist T oder TinC durchaus ausreichend. Wenn es aber eine Funtkion ist, in der zeiten berechnet werden, dann kann T schon wieder missverständlich sein.

Gruß Mümmel

berniebutt

Die alten FORTRAN-Programmierer sind hier in der Minderzahl und mussten sich seinerzeit oft mit 8 signifkanten Zeichen für alles begnügen. Für Schleifen-Variable i, j, k, ... bleibt aber Stand der Dinge.