Wie lang sind die Bezeichnungen Eurer Variablen? Was ist hier noch sinnvoll?

[Guido C. (guidoanalog)]

Hallo,

ich habe heute einen Bekannten, der gerade hinter mir stand, gefragt, ob 
ich meine Variable lieber so oder so benennen solle. Er hat mich 
daraufhin mit mehr oder weniger großen Augen angesehen und sich darüber 
gewundert, dass die Bezeichnungen meiner Variablen so lang sind.

Daher die Frage an Euch. Sind die Bezeichnungen Eurer Variablen auch 
"soooo" lang? Ich nenne die Dinge gerne beim Namen, wie z.B. die 
folgende Bezeichnung für eine Variable von mir:

_Measurement_MinimumForcedNumberOfSamples

Ist die übertrieben?

Mit freundlichen Grüßen
Guido

[Karl H. (kbuchegg)]

Ui, darüber kann man genauso trefflich streiten, wie über die Position 
der {-Klammern.

Für meinen Geschmack ist das schon ein wenig zu lang. Für relativ oft 
vorkommende Wortbestandteile wie zb 'Number' benutze ich meistens immer 
gleiche Abkürzungen, wie dann eben 'Nr' oder 'Min', die die 
Variablennamen verkürzen. Auch hilft das 'Gruppieren' in Strukturen, die 
Variablennamen kürzer zu bekommen, ohne dass der Sinn verloren geht. Zb. 
frage ich mich bei deinem Namen, wo und wie wohl da der Prefix 
'Measurement' zustande kommt und was es mit dem auf sich hat.


Ansonsten: Die Popcorn-Theke ist eröffnet.

[Norbert (Gast)]

Wäre mir persönlich ein wenig zu lang. Ich stelle mir gerade vor wenn 
ich mehrere derart benannte Variablen in einer Zeile benutze.

Ich mache die Namen so kurz wie möglich, jedoch so lang wie nötig damit 
man den Sinn erkennen kann.

Prosa kommt in die Funktionsdokumentation.

[Jörg W. (dl8dtl) (Moderator)]

Die längsten Bezeichner habe ich bislang in Data Generals Sourcecode
für deren DG-UX gesehen.  Wir hatten damals teilweise von denen
Treibercode bekommen, damit wir ihn für unsere MO-Laufwerke modifi-
zieren konnten.  Die damals üblichen VT320-Terminals waren mit der
daraus resultierenden Zeilenlänge deutlich überfordert. :-)

Ich würde es ansonsten ähnlich wie Karl-Heinz halten.  Sehr "kurzlebige"
Variablen (lokale Schleifenindizes oder Hilfs-Zeiger und dergleichen)
bekommen oft auch kurze Namen.  "char *cp" (für "character pointer")
kann's da auch schon mal geben.

Vorsicht übrigens mit Namen, die mit Unterstrichen beginnen.  Zumindest
in C ist ein großer Teil davon reserviert (also Compiler und System-
bibliothek vorbehalten).

[amateur (Gast)]

Wahrscheinlich ist das im wahrsten Sinne des Wortes Geschmacksache. Die 
langatmige Variable ist mit Sicherheit auch nach 5 Jahren noch 
nachvollziehbar und selbsterklärend. Wenn nur die Tastatur vom vielen 
Tippen nicht qualmen würde und die Befehlszeile erst drei Bildschirme 
später zuende wäre.
Soweit mir bekannt wurden bereits ganze Doktorarbeiten über die 
eindeutige und "richtige" Benennung von Bezeichnern geschrieben.

[Karl H. (kbuchegg)]

Mit Schaudern denke ich an einen meiner ehemaligen Professoren im 1. 
Semester zurück, bei dem in den Demonstrationsbeispielen (damals noch 
PL/1) es nur so von

    Dateiverarbeitungsvariable1
    Dateiverarbeitungsvariable2
    ....

wimmelte. (tatsächlich genau so geschrieben, alles in einer Wurscht und 
die entscheidende Veränderung erst ganz zum Schluss).
Man konnte ihm das auch nicht ausreden - Diskussion sinnlos. War eben 
ein altgedienter Siemens-Mann. Die ganze Welt sagt "Enter" bzw. 
"Return". Nur bei Siemens hieß das "Datenübertraguns-Markierer" bzw. 
"Datenübertragungs-Zeichen" :-)

[Dario B. (abcd)]

Ist auch bestimmt nach Vorschrift ;-)

[Reinhard Kern (Gast)]

Hallo,

ist zwar schon eine Weile her, aber ich hatte schon Linker, die nur 7 
Zeichen als relevant betrachteten - ich würde da auch mal nachschauen, 
Linker und OBJ-Formate für unendliche Namen gibt es sicher nicht.

Gruss Reinhard

[Yalu X. (yalu) (Moderator)]

Je globaler, desto länger, aber 41 Zeichen finde ich auch etwas arg
lang. Da braucht das strcmp im Kopf immer so lange, um zwei Namen
miteinander zu matchen.

Noch "lieber" als lange Variablennamen sind mir allerdings lange
Variablennamen, die sich irgendwo in der Mitte in genau einem Zeichen
unterscheiden. Beispiel:

  DrehzahlAbtriebswelle = DrehzahlAntriebswelle * ZaehnezahlAntriebsRad / ZaehnezahlAbtriebsRad;

Jörg Wunsch schrieb:
> Die damals üblichen VT320-Terminals waren mit der
> daraus resultierenden Zeilenlänge deutlich überfordert. :-)

Sogar mit der 132-Zeichen/Zeile-Einstellung? Mein Beileid ;-)

Reinhard Kern schrieb:
> ist zwar schon eine Weile her, aber ich hatte schon Linker, die nur 7
> Zeichen als relevant betrachteten

In Fortran (zumindest den älteren Versionen) waren es nur 6, beim
Apple-Basic 2 und beim Sinclair-Basic 1. Ja, wir haben heute Überfluss,
so weit das Auge reicht ;-)

[troll (Gast)]

Reinhard Kern schrieb:
> Hallo,
>
> ist zwar schon eine Weile her, aber ich hatte schon Linker, die nur 7
> Zeichen als relevant betrachteten - ich würde da auch mal nachschauen,
> Linker und OBJ-Formate für unendliche Namen gibt es sicher nicht.
>
> Gruss Reinhard

Das wollte ich gerade anmerken. Der K&R (und damit vermutlich der 
C-Standard) sagt
> for internal identifiers [...] at least the 31 first characters are
> significant [...]. Internal identifiers include preprocessor macro names
> and all other names that do not have external linkage [...].

> Identifiers with external linkage are more restricted: implementations
> may make as few as the first six characters as significant [...]

[Hui (Gast)]

Bei Objektorientierung ist das noch viel lustiger.

Gerade hier aus einem Java Projekt mal zufällig was rausgepickt:
Toolkit.getDefaultToolkit().getScreenSize().width
oder
javax.swing.plaf.basic.BasicHTML.propertyKey

Und das ist alles noch harmlos und waren nur die ersten paar Sachen die 
mir aufgefallen waren ;-)

Früher mit 640x480er Auflösung musste man Platz sparen.
Heute: Je breiter der Monitor, desto breiter die Bezeichner ;-)

[Hui (Gast)]

Oder auch nicht schlecht:
ToolTipManager.sharedInstance().setLightWeightPopupEnabled(false);

OK das ist ne Funktion aber dennoch ;-)

[Thomas K. (tkroth)]

VariableZurSpeicherungDerXPositionDesCursors=VariableZurSpeicherungDerXP 
ositionDesCursors+SchrittweiteBeiBetaetigungDerTabulatorTaste
;)

[Bassti (Gast)]

Mit nem guten Visual Assistent, kann man auch solche Variablen wie vom 
Threadersteller noch gut handhaben. Meine globalen Variablen sind (die 
längsten) auch so lang und fangen meist mit dem Namen (ggf. der Abk.) 
der Headerdatei und Unterstrich an...

Man schreibt die Headerdatei und die ersten Buchstaben der Variable und 
bekommt schon eine Auswahl, wenn man die Variable gerade benutzt hat 
oder öfter ist sie gleich oben in der Liste und drückt nur noch enter... 
natürlich schreibt man immer noch nicht configuration sondern cfg :D

Alles ganz easy...

[Christian R. (supachris)]

In zeiten von Auto-Vervollständigung, Mouse-Hover usw. sind doch lange 
und vor allem aussagekräftige Variablennamen sehr sinnvoll. So spart man 
sich 90% der stupiden Kommantare. Bei uns auf Arbeit die SW-Entwicklung 
arbeitet komplett so, da gibts nicht einen Kommentar im Quellcode. 
Entweder selbsterklärend oder gar nicht. Aber natürlich hält das jeder 
anders. Wir haben auch einen älteren Kollegen, der immer mal was 
programmiert, das sieht auch ohne Dotfuscator so aus, als wenn er es 
obfuskiert hätte.
a1, b1, count1, count2.....gruselig.

[Mike J. (emjey)]

Wenn ich später wieder mal über den Code schauen muss ist es von Vorteil 
wenn:

1. bei der Deklaration jeder Variable eine kleine Erklärung steht wozu 
sie verwendet wird
2.ich dann über den Code schaue muss der Variablenname schnell 
einprägsam sein.

Nicht so etwas wie "p_clrSpl_qrt", das bringt dir auch nichts wenn du 
immer überlegen musst "Was war das gerade für eine Variable?"

Man kann dann gleich bei der Deklaration jeder Variable eine 
Beschreibung hinzufügen und du benennt jede neue Variable fortlaufend 
v0001, v0002, v0003 ...


Der Quelltext soll sich doch gut lesen lassen.

[Norbert (Gast)]

Christian R. schrieb:
> In zeiten von Auto-Vervollständigung, Mouse-Hover usw. sind doch lange
> und vor allem aussagekräftige Variablennamen sehr sinnvoll. So spart man
> sich 90% der stupiden Kommantare. Bei uns auf Arbeit die SW-Entwicklung
> arbeitet komplett so, *da gibts nicht einen Kommentar im Quellcode.*

zB hierhin!

> Entweder selbsterklärend oder gar nicht. Aber natürlich hält das jeder
> anders. Wir haben auch einen älteren Kollegen, der immer mal was
> programmiert, das sieht auch ohne Dotfuscator so aus, als wenn er es
> obfuskiert hätte.
> a1, b1, count1, count2.....gruselig.

Bist Du sicher das das Wort gruselig nicht weiter nach oben gehört? ;-)

[Verwirrter Anfänger (Gast)]

Je seltener die auftauchen desto länger:

// Schleifenvariablen:
int i,j,h;

// Koordinaten:
int x,y

// temporaerer Buffer für all string operationen
char buffy[80]

// variablen die sofort wieder verwendet werden
int minVal, maxVal, retVal;

// offensichtliche struct variablen
int* screen;
int* parentNode;
FILE* outputFile;


// sehr selten verwendete globale Variablen oder struct member
int numSamplesPerMinute;
float slidingWindowValue;
int horizontalLineOffset;

[Yalu X. (yalu) (Moderator)]

Bassti schrieb:
> Mit nem guten Visual Assistent, kann man auch solche Variablen wie vom
> Threadersteller noch gut handhaben.

Christian R. schrieb:
> In zeiten von Auto-Vervollständigung, Mouse-Hover usw. sind doch lange
> und vor allem aussagekräftige Variablennamen sehr sinnvoll.

Diese Tools erleichtern es zwar lange Namen zu schreiben, aber
irgendwann möchte ja jemand den Quellcode auch wieder lesen. Da sind
überlange Namen minsdestens genauso hinderlich wie zu sehr abgekürzte.

Ein typisches Beispiel für Write-Only-Code :)

> So spart man sich 90% der stupiden Kommantare. Bei uns auf Arbeit die
> SW-Entwicklung arbeitet komplett so, da gibts nicht einen Kommentar im
> Quellcode.

Nee, das ist jetzt nicht dein Ernst, oder?

Quellcode eurer SW-Abteilung sieht also nicht so aus:

double inversInvolut(double x)
{
  /* Umkehrfunktion von tan(x)-x, berechnet mit dem Newtonschen
   * Naeherungsverfahren
   */
  ...
  return y;
}

...

  y = invInvolut(x);

sondern so?

double Umkehrfunktion_von_atan_von_x_minus_x_berechnet_mit_dem_Newtonschen_Naeherungsverfahren(double Funktionsargument)
{
  ...
  return Funktionswert;
}

...

  Funktionswert = Umkehrfunktion_von_atan_von_x_minus_x_berechnet_mit_dem_Newtonschen_Naeherungsverfahren(Funktionsargument);

gruselig :)

[jack (Gast)]

Globale Variablen fangen bei mir immer mit dem Modulnamen (=name der *.h 
Datei) an und haben immer einen Kommentar dabei, zB

/* flag for indicating a successful transmission */
static boolean  UART1_txFinishedFlag;

Mag Einigen, vor allem bei diesem Trivialbeispiel überflüssig 
erscheinen, aber wenn man mal anfängt zu schlampern steigert sich das 
schnell ins Unermessliche. Garnicht erst anfangen.

Bei internen Variablen kürze ich auch gerne ab, wichtiger ist zu 
beschreiben WAS man macht, zB eine kurze Erklärung des Algorithmus. Da 
ist auch "i" oder "tmpPtr" mal erlaubt.

Außerdem finde ich eine wiederkehrende Struktur wichtig, zB. erst alle 
Typdefinitionen, globale Variablen, Modul-globale (static) Variablen, 
Prototypen, etc.

Heftigstes Beispiel für schlechte Struktur, Kommentierung und 
Namensgebung was ich in letzter Zeit sah was der LwIP Stack. Und dazu 
noch die Präprozessorvergewaltigungen, einfach hässlich.
Aber wir sind ja nur bei Variablennamen :-)

CamelCase sollte Pflicht sein, finde ich besser lesbar als lauter 
Unterstriche. Dieser ist ja bei mir schon der Modulkennzeichnung 
vorbehalten.

Aber wie immer, ein weites Feld mit hunderten Meinungen. Wichtiger als 
die eigentliche Namenskonventionen finde ich die strikte Einhaltung 
derselben. Sprich, wenn ich eine Konvention beginne, zieh ich die auch 
konsequent durch. Erst recht wenn mehrere Leute beteiligt sind ist es 
wichtig, einen Standard zu definieren.

[Paul Baumann (Gast)]

Man muß sich sofort unter dem Variablennamen eine Vorstellung machen 
können.

Zum Beispiel:
Dim Horst as Long 'Horst ist 2 Meter groß
Dim Elvira as Single 'Elvira ist geschieden
Dim Erwin as Bit 'Erwin trinkt gerne mal ein Bier
Dim Verdammter_Mist as String*100 'Viel Platz, um Unsinn zu speichern
Dim Kartoffel as Byte
Dim Schnitzel as Byte
Dim Tomatensalat as Integer

'Supp-Routine definieren

Declare Sub Abendbrot

Do
  Print "Mampf!"
  Call Abendbrot 'Abendessen bestellen
Loop until Wampe voll
End



Sub Abendbrot
For Kartoffel=10 to 0 Step-1
   Print "Schmatz!"
   Wait 20 '20 Sekunden bis zum nächsten Bissen warten
Next Kartoffel
Return
End Sub

[Dennis H. (t1w2i3s4t5e6r)]

@Paul

Ein Traum, ein weiteres mal herzlichst über einen deiner Beiträge 
gelacht :)


MfG Dennis

[Muffi (Gast)]

Paul Baumann schrieb:
> Wait 20 '20 Sekunden bis zum nächsten Bissen warten

Ich hoffe, der Aufruf findet nicht in einer ISR statt!

[Paul Baumann (Gast)]

Muffi schrob:
>Ich hoffe, der Aufruf findet nicht in einer ISR statt!

Nein, in der ISR läuft die Verdauung -die muß regelmäßig sein!
;-)
MfG Paul

[Christian R. (supachris)]

Yalu X. schrieb:
> Nee, das ist jetzt nicht dein Ernst, oder?
>
> Quellcode eurer SW-Abteilung sieht also nicht so aus:
> ...
> sondern so?
> ...
> gruselig :)

Doch, genau so. Ist halt deren Philosophie und bisher fahren die sehr 
gut damit. Selbst ich kann deren Quelltext sehr gut lesen und das 
allermeiste auf Anhieb verstehen. Nur bei solchen Sachen wie 
Lambda-Operatoren usw. tu ich mich etwas schwer.
Aber wie ich oben schon schrieb, macht das jeder anders, und solange es 
keine Vorgaben gibt, ist das ja eine Glaubensfrage.

[Marcus B. (raketenfred)]

Yalu X. schrieb:
> double Umkehrfunktion_von_atan_von_x_minus_x_berechnet_mit_dem_Newtonschen_Naeh 
erungsverfahren(double  Funktionsargument)

Also soweit die Nährerung angemessen ist, und das Newtonverfahren 
lediglich ein Werkzeug dabei ist, finde ich reicht:

double atan(double x)
ggf ein double atan_rad(double x), aber wenn eh mit radiant gearbeitet 
wird wie sin,cos,tan es tun. dann braucht 2. nicht

Da ist Mouseover richtig cool, das dann die Doku dazu anzeigt, und da 
gehört dann sowas wie "Newton verfahren Delta =87983241 oder i=9872493; 
return radiant"

[Yalu X. (yalu) (Moderator)]

Christian R. schrieb:
>> Quellcode eurer SW-Abteilung sieht also nicht so aus:
>> ...
>> sondern so?
>> ...
>> gruselig :)
>
> Doch, genau so.

Jetzt machst du mich sprachlos. Ich habe bei dem Beispiel absichtlich
maßlos übertrieben und eigentlich eine Antwort der Art

  "Quatsch, so extrem natürlich nicht. Das sollte ja klar sein, du
   Depp."

erwartet. Und du schreibst einfach

> Doch, genau so.

Ich kann's einfach nicht fassen =8-O

> Doch, genau so.

Meine Kinnlade hängt immer noch in Bauchnabelhöhe.

> Doch, genau so.

Habe ich da irgend einen neuen Trend in der Softwareentwicklung
verschlafen? Heißt der vielleicht ILOP (Identifier Length Oriented
Programming)?

Was macht ihr, wenn in einem Ausdruck mehrere Variablen oder sogar
Unterausdrücke der Form "objekt.member" oder "array[index]" vorkommen?

Werden die Zeilen dann 1000 Zeichen lang, und erstecken sich über drei
nebeneinanderstehende 30"-Monitore?

Oder werden sie umgebrochen?

Oder macht ihr es wie in Bascom, nämlich nur eine Operation pro
Zuweisung zu erlauben?

> Nur bei solchen Sachen wie Lambda-Operatoren usw. tu ich mich etwas
> schwer.

Weil "lambda" so ein extrem kurzer, nichtssagender Name ist? ;-)

[Yalu X. (yalu) (Moderator)]

Marcus B. schrieb:
> Yalu X. schrieb:
>> double Umkehrfunktion_von_atan_von_x_minus_x_berechnet_mit_dem_Newtonschen_Naeh
> erungsverfahren(double  Funktionsargument)
>
> Also soweit die Nährerung angemessen ist, und das Newtonverfahren
> lediglich ein Werkzeug dabei ist, finde ich reicht:
>
> double atan(double x)

Die Funktion im Beispiel ist nicht einfach atan, sondern die
Umkehrfunktion von tan(x)-x.
                         ^^
Da gehört vielleicht schon eine kurze Erläuterung dazu. Und dass diese
Funktion mittels Newton-Verfahren berechnet wird, ist für den Anwender
der Funktion vielleicht uninteressant, aber demjenigen, der die
Implementierung der Funktion verstehen möchte, sollte man das schon
irgendwie mitteilen.

Genau aus dem Grund halte ich es auch nicht für sinnvoll, Detaildokumen-
tation in Funktionsnamen zu packen, weil dann nicht nur derjenige, der
an die Funktion verstehen möchte, sondern auch jeder, der die Funktion
benutzt, mit diesen für ihn unwichtigen Details überhäuft wird.

Aber genau so wird es offensichtlich bei Christian R. gemacht, wenn ich
das richtig verstanden habe.

[Christian R. (supachris)]

Yalu X. schrieb:
> Werden die Zeilen dann 1000 Zeichen lang, und erstecken sich über drei
> nebeneinanderstehende 30"-Monitore?

Quatsch, das wäre dann natürlich auch übertrieben. Aber die Leute haben 
sich zur Aufgabe gesetzt selbsterklärenden Code zu schreiben. Keine 
Ahnung, ob das irgendeinem Trend oder besteimmten Entwicklungsmuster 
folgt. Ich bin Hardware-Entwickler und bei VHDL mach ich´s zwar auch 
möglichst eindeutig und lesbar, aber so ausführlich wie die Softis auch 
wieder nicht. Aber sowas langes wie von dir angeführt ist dann schon 
eher mal die Ausnahme. Sowas wie CalculateImpulseDelaysForAngle(...) ist 
aber völlig normal.

[Läubi .. (laeubi)]

Yalu X. schrieb:
> Genau aus dem Grund halte ich es auch nicht für sinnvoll, Detaildokumen-
> tation in Funktionsnamen zu packen, weil dann nicht nur derjenige, der
> an die Funktion verstehen möchte, sondern auch jeder, der die Funktion
> benutzt, mit diesen für ihn unwichtigen Details überhäuft wird

Besonders spaßig wird es natürlich wenn man dann mal das zugrunde 
liegende Verfahren ändern möchte ;-)

[Christian R. (supachris)]

Läubi .. schrieb:
> Besonders spaßig wird es natürlich wenn man dann mal das zugrunde
> liegende Verfahren ändern möchte ;-)

Rechte Maustaste -> Refactor -> Rename ?

[Yalu X. (yalu) (Moderator)]

Christian R. schrieb:
> Läubi .. schrieb:
>> Besonders spaßig wird es natürlich wenn man dann mal das zugrunde
>> liegende Verfahren ändern möchte ;-)
>
> Rechte Maustaste -> Refactor -> Rename ?

Ein Refactoring der gesamten Software, nur weil sich in einer einzigen
Funktion der Algorithmus geändert hat?

Wie sieht denn das in der Versionsverwaltung aus?

Was ist, wenn die Namensänderung in einer Bibliotheksfunktion gemacht
wird, die von zig Programmen von verschiedenen Entwicklern genutzt wird?

[Sven P. (Gast)]

Solange du nicht an jede Variable völlig sinnfrei ein Typenpräfix 
klebst, wie es sich gnadenlos durchs Win-API zieht, ist alles in 
Ordnung.

Aber wo wir grade VHDL erwähnen: Da benutze ich tatsächlich auch mal 
vergleichsweise (sehr) lange Bezeichner. Das liegt aber im Wesen von 
VHDL. Denn VHDL-Text schreibe ich nicht so herunter und jongliere mit 
Variablen und Funktionen, wie ich es bei der Programmierung mache.

Wenn ich VHDL formuliere, entspricht das eher der Entwicklung eines 
Schaltplanes. Ich rufe eine Funktion nicht so leichtfertig auf, wie man 
es beim Programmieren tun würde, sondern das ist eher eine Art 
Dimensionierung. So wie man einen Transistor mit Geduld und Muße 
auslegen würde, mit Berechnung und Blick ins Datenblatt, so mache ich 
mir Gedanken, wenn ich ein Stück VHDL formuliere. Und da macht ein 
langer Bezeichner garnichts aus.

[hal9000 (Gast)]

"Llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch"
ist der längste Ortsnamen,
Für Variablen sind doch i,j,k lang genug oder?

[Bernd W. (berndwiebus)]

Hallo Guido.


> Daher die Frage an Euch. Sind die Bezeichnungen Eurer Variablen auch
> "soooo" lang? Ich nenne die Dinge gerne beim Namen, wie z.B. die
> folgende Bezeichnung für eine Variable von mir:
>

_Measurement_MinimumForcedNumberOfSamples

>
> Ist die übertrieben?

Meine sind oft noch länger.....und dann kommen noch die Namensräume 
dazu.

Ich lege Wert darauf, schon am Namen zu erkennen, was eine Variable 
macht.
Darum verwende ich auch gerne eine Art "polnischer Notation", bei der 
Variablen einen Prefix erhalten, der ihren Typ beschreibt.

Besonders bei Python, wo die Typendeklaration sehr frei und "intuitiv" 
erfolgt, kann ein Hinweis, was ich in einer Variable eigentlich erwarte, 
und wie ich mir das ganze eigentlich vorgestellt habe, helfen, 
"merkwürdige Effekte" aufzuklären.

Das habe ich auf andere Namen als für Variablen ausgeweitet.

Beispiele:
iAufgabenzaehler (integer)
iAufgabenzaehlerRichtig (integer)
laDistance (keine Variable, sondern Name eines Labels mit Prefix "la")
bReferenceinvisible (boolean)
stGeleseneLine (string)

Ich versuche die Programme kurz zu halten. Wenn sie länger werden, 
versuche ich sie in Bibliotheken aufzudröseln.
Das hält grundsätzlich die Variablennamen kurz. Sie werden bei mir 
länger, je umfangreicher das Programm ist. Nur dann werden die kurzen 
Namen durch die Namensräume wieder länger...;O)

Da sich manche Aufgaben anders entwickeln als geplant, und manche 
Unterprogramme für einen speziellen Zweck aufeinmal anderswo auch 
verwendet werden, weil sie viel universeller einsetzbar sind als 
ursprünglich gedacht, treten darin leider dann auch Bezeichnungen auf, 
die zur neuen Aufgabenstellung eigentlich keinen richtigen Bezug 
haben.....;O)

Mit freundlichem Gruß: Bernd Wiebus alias dl1eic
http://www.dl0dg.de

[Bernd W. (berndwiebus)]

Hallo Yalu

> X.Umkehrfunktion_von_atan_von_x_minus_x_berechnet_mit_dem_Newtonschen_Na 
eherungsverfahren(double
> Funktionsargument)
> {

Wenn ich ein Programm mit vielen Verschachtelungen habe, mache ich das 
auch so. Allerdings verwende ich dann lieber "CamelCode" anstatt der 
Tiefstriche, also so geschrieben: 
X.UmkehrfunktionVonAtanVonX-MinusX-BerechnetMitDemNewtonschenNaeherungsv 
erfahren(double.....

Das wird dann etwas kompakter. Allerdings gibt es Leute, die kriegen ne 
Krise, wenn sie CamelCode lesen müssen. Ich aber nicht. ;O)

Sehr oft verwende ich das auch gemischt mit Tiefstrichen zur Bezeichnung 
von Dateinamen:
"LM1575_LM2575_StepDown_NationalSemiconductor_May1999.pdf" ist zum 
Beispiel ein eingekellertes Datenblatt. Oder 
"RS-274X_ExtendedGerberFormatSpecification_Ucamco_Jan2012.pdf" die 
aktuelle Gerberspezifikation auf der Platte.

Hat den Vorteil, das die Desktopsuche schnell alles findet, schon anhand 
des Dateinamens.

Mit freundlichem Gruß: Bernd Wiebus alias dl1eic
http://www.dl0dg.de

[Forest D. (thecomet)]

> laDistance (keine Variable, sondern Name eines Labels mit Prefix "la")

Das ist jetzt aber nicht Französisch, oder? la distancé

> _Measurement_MinimumForcedNumberOfSamples

> Ist die übertrieben?

Nicht wirklich, nein. Ich sehe aber dass du da eine Mischung zwischen 
Camel-Code und Tiefstriche hast, ich würde da lieber Structs benutzen:

struct Measurement_t
{
   MinimumForceNumberOfSamples
}Measurement;

Dann heisst das Ding so:

Measurement.MinimumForceNumberOfSamples

[Paul B. (paul_baumann)]

And then can manch Einer this nicht lesen, because he is it gewohnt,
in deutscher Language zu writen...
;-)
MfG Paul

[Forest D. (thecomet)]

Ist es wirklich so offensichtlich? :P

[(prx) A. K. (prx)]

Paul Baumann schrieb:
> And then can manch Einer this nicht lesen, because he is it gewohnt,
> in deutscher Language zu writen...

Solange du das tust, kommst ohnehin nicht im Sprachmix herum. Oder 
verwendest du Defines wie
  #define wenn if
  #define andernfalls else
  #define fallunterscheidung switch
  ...

Andere wie ich neigen deshalb umgekehrt dazu, ziemlich konsequent in 
Englisch zu programmieren und nur Kommentare sind machmal gemixt.

[St W. (hallohallo)]

A. K. schrieb:

> Andere wie ich neigen deshalb umgekehrt dazu, ziemlich konsequent in
> Englisch zu programmieren und nur Kommentare sind machmal gemixt.

Ich schreibe auch aussschliesslich in Englisch (Kommentare und Code).

Variabeln benenne ich wie folgt:

unsigned int ui_test_value;

unsigned char uc_something;

[(prx) A. K. (prx)]

NB: Um aber die deutsche Sprache nicht ganz so verkommen zu lassen: Sie 
eignet sich sehr viel besser zum gugeln. Die Wahrscheinlichkeit, mit 
einem zusammengesetzten deutschen Begriff einen Treffer zu landen ist 
sehr viel höher als bei dem englischen Worthaufen gleicher Bedeutung.

[Christian B. (casandro)]

Die beste Lösung findet sich natürlich im Buch "Programming in Prolog". 
Da man in Prolog nur sehr selten mehr als eine Hand voll Variablen hat, 
und die grundsätzlich mit Großbuchstaben anfangen müssen, werden da 
einfach die Großbuchstaben X-Z sowie A-W für Variablen verwendet. Fakten 
und Regeln haben natürlich ausführlichere Bezeichner.

Hier mal ein Beispiel aus der Wikipedia. (gekürzt)

mann(adam).
mann(tobias).
mann(frank).
frau(eva).
frau(daniela).
frau(ulrike).
vater(adam,tobias).
vater(tobias,frank).
vater(tobias,ulrike).
mutter(eva,tobias).
mutter(daniela,frank).
mutter(daniela,ulrike).
grossvater(X,Y) :- vater(X,Z), vater(Z,Y).
grossvater(X,Y) :- vater(X,Z), mutter(Z,Y).
vorfahr(X,Z) :- elternteil(X,Z). 
vorfahr(X,Z) :- elternteil(X,Y), vorfahr(Y,Z).
elternteil(X,Y) :- mutter(X,Y); vater(X,Y).

Wie man sieht, kommt man mit den Variablenbezeichnern X, Y und Z schon 
aus. Alles was klein geschrieben ist sind Fakten bzw Atome.

Und für den Fall, dass einem der Name egal ist, gibts auch noch den 
Unterstrich als Variablenname. Jeder Unterstrich ist eine eigene 
Variable. Schade, dass das in C nicht geht.

[Falk B. (falk)]

Beitrag "Re: Wie lang sind die Bezeichnungen Eurer Variablen? Was ist hier noch sinnvoll?"

Sehe ich auch so. Aber was heißt das schon, bin ja nur Hardwerker ;-)

@  Yalu X. (yalu) (Moderator)

>> Doch, genau so.

>Ich kann's einfach nicht fassen =8-O

>> Doch, genau so.

>Meine Kinnlade hängt immer noch in Bauchnabelhöhe.

>Werden die Zeilen dann 1000 Zeichen lang, und erstecken sich über drei
>nebeneinanderstehende 30"-Monitore?

Naja, jetzt wissen wir, wozu die Turingmaschine wirklich gut ist. Zur 
Verarbeitung extrem langer Variablennamen! Demnächst mit USB-Port 
verfügbar ;-)

Ich würde die Variable des OP so schreiben, guter Kompromiss aus Länge 
und Lesbarkeit.

Meas_Min_Num_Samples

[Yalu X. (yalu) (Moderator)]

Christian Berger schrieb:
> Und für den Fall, dass einem der Name egal ist, gibts auch noch den
> Unterstrich als Variablenname. Jeder Unterstrich ist eine eigene
> Variable. Schade, dass das in C nicht geht.

Naja, in C hat man auch recht selten ungenutzte Variablen. Diese
"Joker"-Underscores sind eigentlich nur sinnvoll in Programmiersprachen
mit Pattern-Matching oder Unification.

[keinLichtAufGing (Gast)]

Hi,

@Yalu X, Christian R.:
Da habt Ihr mich an was erinnert...

Auf der Arbeit kannte ich auch einen Kollegen der genau diese Art
Programmierung überzeugt vertritt ("Ein Programmtext muss ohne
Kommentare absolut verständlich sein und sich wie ein Text/LH
lesen lassen, sonst hat der Entwickler was falsch gemacht!
Kommentare sind eh meistens veraltet!").

Der ist aber ein Einzelfall, keine ganze Abteilung. Ist mir aber
trotzdem nach den Postings wieder aufgefallen... Gab es da
vielleicht mal eine "Denkschule" oder Uni, die diese Technik
vertreten/gelehrt hat? Weisst Du dazu was?

Ich vermute, dass diese Technik in den 70er/80er Jahren entwickelt
wurde, als die Softwarekrise mit voller Wucht zuschlug und die
Forderung nach "einfachen" Programmen aufkam. Gefühlsmässig würde
ich bei Dijkstra oder Wirth zu suchen beginnen.

Grüssli

[Christian R. (supachris)]

Wie gesagt, weiß ich nicht, woher die das haben. Ist aber bei uns 
unproblematisch, da es ein sehr homogenes Team von weniger als 10 Leuten 
(alle um die 30) ist und die Software nur ganz selten in Teilen (SDK) 
aus dem Haus geht. Ich find das nicht schlecht, dadurch haben alle ein 
hohes Maß an Verständnis für das, was sie da machen, das wird durch das 
Team-Rotating noch unterstützt.
Aber wie schon geschrieben ist das eine Glaubensfrage, wenn es keine 
Vorgaben gibt, kann doch jeder machen was er will oder mag.

[Arc N. (arc)]

keinLichtAufGing schrieb:
> Ich vermute, dass diese Technik in den 70er/80er Jahren entwickelt
> wurde, als die Softwarekrise mit voller Wucht zuschlug und die
> Forderung nach "einfachen" Programmen aufkam. Gefühlsmässig würde
> ich bei Dijkstra oder Wirth zu suchen beginnen.
>
> Grüssli

Wirth mit sehr, sehr hoher Wahrscheinlichkeit nicht...

Einfach mal in die unter
http://www.ethoberon.ethz.ch/books.html als PDF vorliegenden Bücher 
sehen...

Bei Dijkstra kann ich mir das auch nicht vorstellen (Physik studiert, 
viel Mathematik/theoretische Probleme untersucht -> wenn es hoch kommt, 
einsilbige Wörter z.B. 
http://www.cs.utexas.edu/users/EWD/transcriptions/EWD01xx/EWD123.html 
(Semaphoren))

[Thomas (Gast)]

"_Measurement_MinimumForcedNumberOfSamples"

Würde ich Meas_MinForcedNumSamples nennen.

_am Anfang geht gar nicht (persönliche Meinung).

[Bernd W. (berndwiebus)]

Hallo Forest Dump.

>> laDistance (keine Variable, sondern Name eines Labels mit Prefix "la")
>
> Das ist jetzt aber nicht Französisch, oder? /la distancé/

Nein. Das Label gibt eine Distanz aus. Und weil ich das nicht im Blick 
hatte, das es sich um ein Label (das Widget) handelte, hatte ich nach 
einer
Programmierpause das Label "Distance" (englisch) wie eine Variable 
verwendet. Das führte zu Fehlern. Darum habe ich aus "Distance" halt 
"laDistance" gemacht, analog zur "ungarischen Notation", mit "la" für 
Label. (http://de.wikipedia.org/wiki/Ungarische_Notation), die ich in 
obigem Beitrag auch noch fälchlicherweise als "polnische Notation" 
bezeichnete.

Da ich auch dazu tendiere, den Überblick über meine verwendeten 
Variablen zu verlieren, ist es mir wichtig, am Variablennamen auch 
direkt den Typ zu erkennen. Sehr nützlich auch bei Typkonvertierung: Aus 
iVariablenname wird strVariablenname oder umgekehrt. ;O)

Mit freundlichem Gruß: Bernd Wiebus alias dl1eic
http://www.dl0dg.de

[.... (Gast)]

Bernd Wiebus schrieb:
> Da ich auch dazu tendiere, den Überblick über meine verwendeten
> Variablen zu verlieren, ist es mir wichtig, am Variablennamen auch
> direkt den Typ zu erkennen.

Mag ich gar nicht. Wenn man halbwegs bei Sinnen ist, ergibt sich der Typ 
der Variable ja von selbst aus dem Kontext. Es mag Ausnahmen geben, wenn 
z.B. numerische Berechnung mit unterschiedlichen Typen gemacht wird.

[Jörg W. (dl8dtl) (Moderator)]

Christian Berger schrieb:
> Und für den Fall, dass einem der Name egal ist, gibts auch noch den
> Unterstrich als Variablenname. Jeder Unterstrich ist eine eigene
> Variable. Schade, dass das in C nicht geht.

Ein Unterstrich als Variable?  Geht auch in C. ;-)

Macht allerdings niemand.  Aber: was sehr gängig ist ist, den
Unterstrich als (funktionsartigen) Makro zu benutzen:

  printf(_("Hello world!\n"));

Der Unterstrich wird dabei durch einen Aufruf von gettext() ersetzt,
aber er stört halt den Lesefluss des Programms fast nicht.

[Yalu X. (yalu) (Moderator)]

Christian Berger schrieb:
> Und für den Fall, dass einem der Name egal ist, gibts auch noch den
> Unterstrich als Variablenname. Jeder Unterstrich ist eine eigene
> Variable. Schade, dass das in C nicht geht.

Ein Unterstrich als Variable?  Geht auch in C. ;-)

Christians Betonung lag, glaube ich, auf

> Jeder Unterstrich ist eine eigene Variable.

In Prolog ist bspw. folgende Term erfüllbar (also true)

  append([1,2,3,4], [_,_], [1,2,3,4,5,6]).

weil man für den ersten Underscore den Wert 5 und für den zweiten den
Wert 6 einsetzen kann. Das geht, weil die beiden Underscores unter-
schiedliche Variablen sind.

Hingegen ist der Term

  append([1,2,3,4], [X,X], [1,2,3,4,5,6]).

nicht erfüllbar (also false), weil das rechte Argument mit zwei unter-
schiedlichen Werten (5 und 6) endet, und X nicht beide Werte gleich-
zeitig annehmen kann.

Aber wie ich oben schon schrieb:

> Diese "Joker"-Underscores sind eigentlich nur sinnvoll in
> Programmiersprachen mit Pattern-Matching oder Unification.

Und beides gibt es in C nicht.


Aber nochmals zurück zu den langen Variablennamen:

Wieso diskutieren die Programmierer eigentlich darüber, ob Variablen-
namen 10, 20 oder 40 Zeichen lang sein sollten, während die Mathematiker
und Physiker ganze Bücher voller Formeln schreiben, in denen fast nur
Variablennamen der Länge 1 vorkommen?

[Georg A. (georga)]

> während die Mathematiker und Physiker ganze Bücher voller Formeln
> schreiben, in denen fast nur Variablennamen der Länge 1 vorkommen?

Die nutzen aber auch unzählige Zeichensätze und Schnörkel-Anhängsel 
(Strich, Dach, Sternchen, ...) dafür ;)

[Guido C. (guidoanalog)]

Hallo,

vielen Dank für die tollen Beiträge. Ich finde es immer wieder 
interessant zu lesen, wie die Leute ihre Quelltexte gestalten. Vor allen 
bin ich beruhigt, dass nicht nur ich etwas längere Variablennamen 
benutze.

Zu meinem Beispiel

_Measurement_MinimumForcedNumberOfSamples

möchte ich noch folgendes anmerken: Grundsätzlich bin ich eher ein 
Anhänger von CamelCase. Unterstriche benutze ich selten. Das aufgeführte 
Beispiel stammt aus einer imc FAMOS-Sequenz, die ich geschrieben habe 
(http://www.imcfamos.de). Bei FAMOS handelt es sich um einen 
Interpreter. Für alle Variablen innerhalb von FAMOS existiert nur ein 
Gültigkeitsbereich, d.h. die Hauptsequenz muss sich diesen Bereich mit 
den Untersequenzen teilen. Dies ist der Grund, weshalb ich mir in FAMOS 
angewöhnt habe in Abhängigkeit von der Sequenz einen Präfix 
voranzustellen. Diesen trenne ich mit einem "_" ab. Der vorangestellt 
"_" dient lediglich dazu, dass ich am Ende alle Variablen, die ich nicht 
mehr benötige mit einem Befehl Löschen kann (Entfernen _*). Wichtige 
Variable haben keinen vorangestellten "_".

Mein Ziel ist es natürlich auch Programmcode zu erstellen, der ohne 
weitere Erklärung verstanden werden kann. Ich denke der erste Schritt 
hierzu ist eine vernünftige Wahl der Variablennamen. Selbst wenn der 
Code einfach und verständlich ist, ein Kommentar fehlt bei mir nie. Mir 
ist auch schon aufgefallen, dass Personen, die mit meinem Code nicht 
vertraut sind eher auf die Kommentare achten.

Mit freundlichen Grüßen
Guido

[Yalu X. (yalu) (Moderator)]

Georg A. schrieb:
> Die nutzen aber auch unzählige Zeichensätze und Schnörkel-Anhängsel
> (Strich, Dach, Sternchen, ...) dafür ;)

Bei der Programmierung ist ein Anfang dazu ja bereits gemacht.
Folgendes ist legaler Python-Code:

ω  = 9.5
φ  = 0.2
Δt = 0.01
Û  = 5.0

for i in range(100):
  t = i * Δt
  U = Û * sin(ω*t+φ)
  print(t, U)

Und Python ist nicht die einzige Programmiersprache, die so etwas
ermöglicht.

Falls dies zu einem Trend werden sollte: Können wir dann in Zukunft auf
Monstervariablen wie im Eingangspost verzichten, ohne dass der Code
dadurch unverständlich wird?

[Guido C. (guidoanalog)]

Hallo,

Yalu X. schrieb:
> Bei der Programmierung ist ein Anfang dazu ja bereits gemacht.
> Folgendes ist legaler Python-Code:
> ω  = 9.5
> φ  = 0.2
> Δt = 0.01
> Û  = 5.0
>
> for i in range(100):
>   t = i * Δt
>   U = Û * sin(ω*t+φ)
>   print(t, U)

liest sich doch gar nicht schlecht. Einzig die Eingabe von ω, φ, usw. 
gestaltet sich derzeit bei den meisten Editoren noch als Geduldsprobe.

Mit freundlichen grüßen
Guido

[Yalu X. (yalu) (Moderator)]

Guido C. schrieb:
> Einzig die Eingabe von ω, φ, usw.
> gestaltet sich derzeit bei den meisten Editoren noch als Geduldsprobe.

Da der Trend sowieso immer mehr in Richtung "Klicken statt Tippen" geht,
ist das vielleicht gar kein so großes Problem :)

Und die ewig Gestrigen, die noch Vim benutzen (auch ich gehöre dazu),
schaffen's auch ohne Klicken recht schnell:

  ^kw* → ω
  ^kf* → φ
  ^kD* → Δ
  ^kU^ → Û

Das geht schneller zu tippen als "kreisfrequenz", "phasenverschiebung"
usw., selbst wenn man für die langen Namen Autocompletion benutzt.

[Guido C. (guidoanalog)]

Hallo,

Yalu X. schrieb:
> Da der Trend sowieso immer mehr in Richtung "Klicken statt Tippen" geht,

und derzeit kommt noch das "betouchen" des Monitors hinzu.

Mit freundlichen Grüßen
Guido