Wie lang sollte ein Variablenname maximal sein?

[Namenslänge]

Bashar schrieb:

In einem Programm, in dem eine Temperatur vorkommt, kommen auch noch andere Temperaturen vor. Die Frage ist also überhaupt nicht, ob man die Einheit oder was auch immer in den Namen eincodiert, sondern wie man die verschiedenen Bedeutungen auseinanderhält: Temperatur, bei der die Heizung oder Kühlung ein- oder ausgeschaltet werden soll, gemessene Temperatur, geschätzte Temperatur, gewünschte Temperatur tagsüber/abends/nachts, tatsächliche/erwartete Außentemperatur, Temperatur des Leitungswassers/Kühlwassers, Abgastemperatur usw. Ich hab noch keine Temperaturregelung oder sowas programmiert. Aber ich wette, dass die in der Praxis nicht alle das Wort "Temperatur" im Variablennamen haben, und die Einheit schon gar nicht.

Okay, nehmen wir mal an, wie schreiben ne Software für ne Haussteuerung, bei der einfach alles gesteuert wird.
Also der Status der Rollläden 1-25 in Prozent, also wie weit sie geschlossen sind.
Dann die Luftfeuchtigkeit in den verschiedenen Räumen, die ganze Steuerung zu der Beleuchtung, wobei man hier auch berücksichtigen muß, das nicht alle Lichter nur ein und aus kennen, sondern es auch Lampen gibt, die man schwächer runterregeln kann, hier ist also wieder ein Status in Prozent notwendig.
Oder man hat überall Lichtsensoren die in Candela messen.
usw.

Auf jedenfall reicht es dann nicht mehr, die Variable wie du sagst, einfach Messwert_von_Esszimmer zu nennen, denn dann muß man schon schreiben Temperaturmesswert_von_Esszimmer oder so ähnlich.

[Bashar]

Namenslänge schrieb:

Auf jedenfall reicht es dann nicht mehr, die Variable wie du sagst, einfach Messwert_von_Esszimmer zu nennen

Das hab ich doch gar nicht gesagt.

[asc]

Ein Variablenname sollte so lang sein, das sich der Sinn der Variable auch für die erschließt, die sich neu in eine Software einarbeiten.

Im Zweifel halte ich meine Namen lieber etwas zu lang, falls ich aber eine verständliche, kürzere Form finde, wähle ich diese. So kann es durchaus mal sein das in der ersten Niederschrift eine Variable auch mal 30 Zeichen lang ist, aber vielleicht später ein wesentlich kürzerer lesbarer Name einfällt.

Falls es z.B. wichtig ist darauf hinzuweisen das die Temperatur in Celsius gemeint ist, würde ich wohl mit temperaturCelcius anfangen; falls im gesamten Programm einheitlich mit einer Einheit gearbeitet wird, würde ich wohl auf das Celsius verzichten.

[hustbaer]

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.

[Wutz]

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.

[Shiba]

Regel schrieb:

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

Guter Witz
Hier
http://mindprod.com/jgloss/unmainnaming.html
gibts noch mehr gute Handreichungen, wie man Variablen benennen soll.

Ansonsten sollte der Name der Variable deutlich sagen, wozu die da ist.
Und da stimme ich mit Bashar überein, dass eine Benennung nach Einheit nicht unbedingt sinnvoll ist.
Namensbegründungen, wie ist zu lang oder ich weiß, doch was t bedeutet, sind nett. Besonders fein sind Variablennamen wie lfz1 (erste Laufzeit) und lfzl (Laufzeit lang) zusammen in einer Funktion/einem Block.

Falls so etwas in größeren, langfristigen Projekten stattfindet, sollte der Entwickler Adresse und Telefonnummer für den nachfolgenden Maintainer hinterlassen. Dann kann dieser seine Freude über wundervollen Code direkt dem Schöpfer bekunden.

[hustbaer]

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.

[muemmel]

Hi,

ansiskrien schrieb:

berniebutt schrieb:

Maximal heute (fast) beliebig.

Mehr als eine Bildschirmgrösse (nach ISO/ANSI 80 Zeichen breit) sollte es dann doch nicht sein.

Also auf meinem Bildschirm sehe ich 225 Zeichen, glaube aber, dass das für einen Variablennamen ein kleines bisschen lang ist. :xmas1:

Allgemein kann man wohl sagen, dass all die Variablennamen bei denen man alle Vorkommen (Definition und Verwendung) innerhalb einer Bildschirmseite im Blick hat kürzer sein können als die auf die das nicht zutrifft.
Kommentare sollten besser nicht angeben, was damit gemeint ist, sondern eher warum die Variable gebraucht wird und welche sonstigen Bezüge sie hat.

Im Fall der Temperatur ist es aber doch nicht so einfach. Überall wo es mehr um physikalische Probleme geht, oder sonst wie °C und °F auftreten können würde ich eine Klasse verwenden, die C und F entsprechend verarbeitet und für Differenzen oder Veränderungen Grad nimmt.

Als einfache Laufwariablen oder Schleifenvariablen in kurzen Schleifen, wo sich das aus der Sache selbst erklärt nehme ich aber aus alter Fortran-Gewöhnung auch heute noch gerne i, j, k, l, m, n. Da weis ich dann aus dem Namen heraus schon, dass das einfach nur zum hochzählen da ist. :xmas2:

Gruß Mümmel

[muemmel]

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

[volkard]

muemmel schrieb:

wenn einem 31 Zeichen nicht reichen, sollte man ggf mal über seinen Programmierstil nachdenken.

Kommt vor. Und durch Nachdenken bin ich dazu gekommen, daß lange Namen manchmal gut sind.

[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.

[Idee]

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.

[Regel]

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;

[roflalter]

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.