Programmierstil - Grundsatzfrage

Mechanics

z ist schon deutlich seltener. Ich hab schon viele Funktionen gesehen, die nichts mit Kooordinaten zu tun haben, bei denen die Parameter aber x und y heißen.

hustbaer

Ja, gut.
x, y, z sind OK.
Zumindest wenn es wirklich Koordinaten sind und aus dem Kontext sofort klar ist um welches X, Y und Z es sich dabei handelt.

Bei Vergleichsfunktionen ist auch OK x und y zu nehmen oder auch a und b.

Viel mehr fällt mir dann aber wirklich nicht mehr ein.

hustbaer schrieb:

Bei Vergleichsfunktionen ist auch OK x und y zu nehmen oder auch a und b.

Für Vergleichsfunktionen verwendet man lhs und rhs (lihnks und rechts).

hustbaer

@lihnks
Ja.
Wenn man Pedant und/oder doof ist.
Realistischerweise muss man aber sagen: lhs und rhs sind optisch VIEL zu ähnlich und daher schlecht.
a und b ist besser.

Hier ist Code von der neuen haskell.org Eingangsseite:

primes = filterPrime [2..] 
  where filterPrime (p:xs) = 
          p : filterPrime [x | x <- xs, x `mod` p /= 0]

Man sieht sowohl ausgeschriebenes wie auch Kürzel. Da der Code nicht erklärt wird, ist eher vermutlich selbsterklärend genug. Es kommt wie gesagt (genau wie in gesprochenen Sprachen) auf den Zusammenhang an (wie z.B. auch Schreib- oder zur Thematik generell): Lesefaulheit. Wenn man alles und jedes ausschreibt, kann das in gewissen Kreisen oder Programmteilen wie Obfuscation wirken.

Ohne Xing erfolgreich schrieb:

Mechanics schrieb:

hustbaer schrieb:

Ist aber auch so ziemlich der einzige 1-Buchstabenname der OK ist.

Was ist mit x, y?

Du hast z vergessen.

und:
r, g, b, a (selbsterklärend),
n, m (Matrixdimensionen),
i, j (Matrix zeilen/Spaltenindex),
r (Radius),
t (Zeit),
c (char),

es gibt eigentlich eine ganze Reihe 1-buchstabiger Variablennamen, die verstanden werden.

Daß ein ideales C/C++ Programm so selbsterklärend wie möglich sein sollte, stimmt zwar. Bei Programmiersprachen wie TeX oder apl kann das aber anders aussehen. Da wäre ein unkommentiertes Programm nicht immer ideal.

Gregor

großbuchstaben schrieb:

und:
r, g, b, a (selbsterklärend),
n, m (Matrixdimensionen),
i, j (Matrix zeilen/Spaltenindex),
r (Radius),
t (Zeit),
c (char),

es gibt eigentlich eine ganze Reihe 1-buchstabiger Variablennamen, die verstanden werden.

Ich freue mich immer über so kurze Variablennamen, wenn ich mal keine IDE zur Verfügung habe sondern nur einen einfachen Editor und dann nach diesen Variablen suche.

Gregor schrieb:

Ich freue mich immer über so kurze Variablennamen, wenn ich mal keine IDE zur Verfügung habe sondern nur einen einfachen Editor und dann nach diesen Variablen suche.

Diese Variablen leben sowieso nur höchstens 5 Zeilen, von daher tritt das Problem nicht auf.

SeppJ

flotterfuenfer schrieb:

Gregor schrieb:

Ich freue mich immer über so kurze Variablennamen, wenn ich mal keine IDE zur Verfügung habe sondern nur einen einfachen Editor und dann nach diesen Variablen suche.

Diese Variablen leben sowieso nur höchstens 5 Zeilen, von daher tritt das Problem nicht auf.

Nicht r, g, b, a, r (fällt dir was auf?) oder t, oft auch n und m.

SeppJ schrieb:

flotterfuenfer schrieb:

Diese Variablen leben sowieso nur höchstens 5 Zeilen, von daher tritt das Problem nicht auf.

Nicht r, g, b, a, r (fällt dir was auf?) oder t, oft auch n und m.

Doch, auch die. r, g, b, a als struct-Member sind extrem unhandlich. Die speichert man vielleicht als

struct color { array<uint8_t, 4> rgba; };

oder als

using color = math::vector<float, 4>;

t habe ich noch nicht so häufig in einer Klasse gesehen, denn t ist normalerweise das, was sich verändert und das ist dann ein Parameter einer Funktion. Als solche können auch r, g, b, a vorkommen (oder z.B. Konstruktor). Aber dann leben sie auch kurz. Wenn t dann doch mal in einer Klasse vorkommt, kann man auch time schreiben, aber meistens passt dan ein anderer Name besser.

Genauso ist es mit n und m. Man braucht gar nicht erst beide speichern.

r (klar habe ich das gemerkt, sie stehen ja nahe beieinander) habe ich lieber als radius, weil ich lokal dann auch oft gerne ein r hätte, und so vermeide ich eine Namenskollision.

SeppJ

Also kurz: Je kleiner der Gültigkeitsbereich einer Variablen ist, desto lässiger kann man bei der Namensgebung vorgehen. Aber umgekehrt bitte bloß nichts mit nur ein oder zwei Buchstaben und einem Gültigkeitsbereich, der über eine einzelne (Member-)Funktion hinaus geht! Egal für wie einleuchtend man "m" als Bezeichnung für die Spaltenanzahl empfindet.