Wie lang sollte ein Variablenname maximal sein?

camper

hustbaer schrieb:

pumuckl schrieb:
314159265358979 schrieb:
nehmen. Wenn ich viel mit verschiedenen Einheiten rechne, dann würde ichs im Typ festhalten.
template <int m, int kg, int s, int A, int K, int mol, int cd>
Ich würde als Template-Parameter nicht die Einheiten, sondern die Dimensionen nehmen. Bei deinem Template kriegt man z.B. mit Litern schon Schwierigkeiten.
template <int length, int mass, int time, int temperature = 0 /* mehr Dimensionen */>
class Quantity
{
  /* Speichern des Wertes in SI Grundeinheiten */
  double value;
};
Ist doch genau das selbe wie Pi macht, nur dass du deine Template-Parameter anders nennst

In beiden Fällen entsprechen die Template-Parameter den Exponenten der SI-Basiseinheiten. Und der Wert wird immer ohne "scale" abgespeichert, also ein Liter ist dann eine Quantity<3, 0, 0, ...> mit value = 0.001.

Die Spezifikation der Dimension ist doch etwas ganz anderes die Festlegung bestimmter Größen als Bezugsgrößen. Insofern hat pumuckl schon recht, nur der Kommentar ist fehlgeleitet.

template <int length, int mass, int time, int temperature = 0 /* mehr Dimensionen */>
class Quantity
{
  double value;
};

const Quantity<1,0,0> meter = { 1. };
Quantity<1,0,0> my_length = { 55. };

cout << "meine Länge " << my_length.value / meter.value << " Meter";

Ein Kilogramm oder ein Meter oder eine Sekunde sind schließlich durch nichts speziell gegenüber 2 Kilogramm, 2 Meter, 2 Sekonden etc. ausgezeichnet. Diese Grundeinheiten dienen nur dazu andere Größen als direkte Verhältnisse (also einfache Zahlen) relativ ziu diesen Grundmaßen auszudrücken. Insofern ist die konkrete Wahl des internen Wertes für dieses Grundmaß völlig irrlevant (wobei 1 nat. bequem ist), schließlich muss bei jeder Ein- und Ausgabe dieses Verhältnis - im Prinzip - neu gebildet werden.

hustbaer

camper schrieb:

Ein Kilogramm oder ein Meter oder eine Sekunde sind schließlich durch nichts speziell gegenüber 2 Kilogramm, 2 Meter, 2 Sekonden etc. ausgezeichnet. Diese Grundeinheiten dienen nur dazu andere Größen als direkte Verhältnisse (also einfache Zahlen) relativ ziu diesen Grundmaßen auszudrücken. Insofern ist die konkrete Wahl des internen Wertes für dieses Grundmaß völlig irrlevant (wobei 1 nat. bequem ist), schließlich muss bei jeder Ein- und Ausgabe dieses Verhältnis - im Prinzip - neu gebildet werden.

Ich verstehe was du meinst. Ich sehe es aber trotzdem anders. Ich würde nie auf die Idee kommen intern mit etwas anderem als den SI Einheiten zu rechnen. Oder gar überhaupt keine Bezugsgrösse festzulegen.

Genau so wie ich keine Datums/Zeit Library kenne die nicht intern fix mit einer bestimmten Bezugsgrösse rechnet. Das sind nicht immer Sekunden, oft sind es Millisekunden, manchmal Nanosekunden, aber es ist fix.

Schonmal deswegen, weil man sonst nicht vernünftig rechnen kann. Wenn manche Werte in Metern skaliert sind, und andere in Millimeter oder in Zoll, dann kann man die nichtmal addieren...
Klar, man kann sagen "der User soll sich drum kümmern".

Ich meine aber dass das genau so lästig wäre, wie es lästig ist dass es in C++03 keine char-/String-Typen gibt die ein Encoding implizieren/definieren.

GoaZwerg

Also im Buch "Clean Code" erklärt der Autor das dies:

int Delay; // in seconds

schlechter sei als das:

int DelayInSeconds;

Und genau so halten wir das (meistens) auch auf der Arbeit.

Auch wenn der Variablenname dadurch sicherlich länger wird, ich finde es persönlich besser, vor allem wenn man sich durch den Code von Kollegen wühlen muss

Wobei ich aber auch einen Kollegen hab, der Stumpf sowas macht:

int a; int b; int c;

Also in dem Fall wäre mir die erste Variante auch noch lieber

Ich würde mal sagen: nen gesundes Mittelmaß finden!

volkard

GoaZwerg schrieb:

Ich würde mal sagen: nen gesundes Mittelmaß finden!

Dem schließe ich mich doch mal gerne an.

*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

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?

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.