Wie lang sollte ein Variablenname maximal sein?

Wutz

hustbaer schrieb:

Wutz schrieb:

Namenslänge schrieb:

Aber welche Variablennamenlänge sollte man als Richtwert überhaupt wählen?
< 12 Zeichen, < 20 Zeichen oder gar größer?

Größer aber bei ANSI C nur bis max. 31 Zeichen für interne Namen, 6 bei externen.
Nur hierfür garantiert der Standard/Compiler die Signifikanz.

Und deswegen sollte man bei C jetzt seine Namen kastrieren?
Also ne, sicher nicht.
Reale Compiler fressen wesentich längere Namen, ich sehe also keinen Grund in realen Programmen nicht auch längere Namen zu verwenden.

Ich habe nicht gesagt, dass du deine Variablen auf max. 31 Zeichen kürzen sollst, ich habe gesagt, dass (nur) die ersten 31 Zeichen gemäß Standard signifikant sind, du kannst die dann beliebig erweitern und eine dir genehme Beschreibung in den Variablennamen einfließen lassen.
Das nächste Limit liegt dann bei 509 Zeichen, wie auch für Stringliterale.

muemmel schrieb:

Hi,

hustbaer schrieb:

Wutz schrieb:

Größer aber bei ANSI C nur bis max. 31 Zeichen für interne Namen, 6 bei externen.

Und deswegen sollte man bei C jetzt seine Namen kastrieren?
Also ne, sicher nicht.
Reale Compiler fressen wesentich längere Namen, ich sehe also keinen Grund in realen Programmen nicht auch längere Namen zu verwenden.

wenn einem 31 Zeichen nicht reichen, sollte man ggf mal über seinen Programmierstil nachdenken.
Mit Namen die sihc erst nach der 31. Stelle unterscheiden und vom Compiler her als gleich angesehen werden, erzeugt man sich wunderschöne unerklärliche Effekte, an denen man sich unter Umständen einen Wolf sucht.
Man definiert in einer Funktion eine Variable, die sich von einer externen Variable unterscheidet. Auf Grund der Länge übedeckt diese jedoch die externe Variable, so dass alle Zugriffe immer bei der lokalen Variable landen.
Da daraus ein für den Menschen völlig korrektes Programm entsteht, das auch für den Compiler völlig korrekt ist, nur von beiden unterschiedlich verstanden wir, ist da Chaos und Überstunden vorbereitet.

Gruß Mümmel

Vielleicht sollte man besser die Compiler ausgrenzen, die mehr als 31 Zeichen nicht beherrschen.
Dadurch erspart man sich das Wolf suchen.

Guter Witz

War kein Witz!

Die Regel funktioniert erstaunlich gut. Ich muss zugeben, ich programmiere in letzter Zeit fast nur noch in Haskell, wo sehr kurze Funktionen (und damit ein sehr beschränker Gültigkeitsbereich) keine Seltenheit sind.
Aber auch in imperativen Sprachen funktioniert das gut. Z.B. 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

auto mySpeed = 54.0kmh;
  auto myMass = 84.4kg;
  auto myKineticEnergy = mySpeed * myMass;

das hier schreiben:

auto v = 54.0kmh;
  auto m = 84.4kg;
  auto e_kin = v * m;

JodaDateTimeFormatAnnotationFormatterFactory - 44 zeichen

berniebutt

int DiesesThemaWegenLangerVariablenMitMehrAls31ZeichenIstIrgenwannEinmalZiemlichUnsinnig_daddeldu=1;

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