Wie lang sollte ein Variablenname maximal sein?

[*Rewind*]

Regel schrieb:

Einfache Regel: Je kleiner der Gültigkeitsbereich der Variablen, desto kürzer kann der Variablenname sein.

Das sehe ich aber anders. Wie viele schon gesagt haben, ist die Lesbarkeit ein wesentlicher Faktor und sollte auch in kleinen Gültigkeitsbereichen nicht vernachlässigt werden, denn es kommt nicht selten vor, dass man innerhalb einer Schleife viele "temporäre" Variablen einsetzen muss.

[GoaZwerg]

Da muß ich [Rewind] beipflichten, was nützt mir ne Methode mit lokalen Variablen die alle kryptische Bezeichner wie "a", "b", "c" tragen (wie es mein Kollege ständig macht). Da blickt nach wenigen Wochen doch keine Sau mehr durch (nicht mal der, der den Kram verbrochen hat - finde ich jedenfalls aus Erfahrung)...

Ergänzung (Edit):

in dem erwähnten Buch steht auch, dass Kommentare nur beschreiben sollten WARUM man etwas macht - nicht WAS man macht. Auch wenn das Buch durchaus kritisch ist an einigen Punkten, so finde ich das sinnvoll (hoffe das geht jetzt nicht zu sehr ins "Off-Topic").

Wieviele Kollen machen (in VB) sowas:

' Connection öffnen
connection.Open()

' Spaghetti-Code

' Connection schließen
connection.Close()
connection.Dispose()

Aha! Wow Schon mal was von USING gehört? Nee, egal - okay Aber ganz ehrlich: DIESE Kommentare bringen wohl NIEMANDEN aus der ganzen Abteilung irgendwie weiter

[Regel]

Das sehe ich aber anders. Wie viele schon gesagt haben, ist die Lesbarkeit ein wesentlicher Faktor und sollte auch in kleinen Gültigkeitsbereichen nicht vernachlässigt werden, denn es kommt nicht selten vor, dass man innerhalb einer Schleife viele "temporäre" Variablen einsetzen muss.

Wenn man viele temporäre Variablen einsetzt, ist der Gültigkeitsbereich auch nicht mehr wirklich klein. Mit einem kleinen Gültigkeitsbereich meine ich wirklich vielleicht 5-zeilige Funktionen. Da kann man dann auch mal einfach Connection c; statt Connection conn; oder gar Connection connection; // A connection schreiben.
Und für größere Gültigkeitsbereiche nimmt halt längere Namen. Wie gesagt, eine einfache Regel, mit der ich aber nur gute Erfahrungen gemacht habe.

Natürlich, einbuchstabige Bezeichner sind extrem und kommen auch bei mir in imperativen Code sehr selten vor (außer als Zählvariable - da haben sich i, j und k eingebürgert).

[GoaZwerg]

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.

[knivil]

Lesbarkeit wird nicht unbedingt durch laengere Variablennamen erhoeht.

[GoaZwerg]

Sondern? Durch was?

[cooky451]

GoaZwerg schrieb:

Sondern? Durch was?

Durch lolcats. lolcats ist immer positiv. Ansonsten vielleicht durch gute und prägnante Namen, zudem durch eine übersichtliche Code-Struktur, die verschiedenen Abschnitten klare Aufgaben zuteilt. Aber das spielt wohl nur eine untergeordnete Rolle, die lolcats regeln.

[*Rewind*]

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.

[GoaZwerg]

lolcats?
Was ist das?

[Fast2_unreg]

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.

[Regel]

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.

[double x, y, z;]

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.