Programmierstil - Grundsatzfrage

"Selbsterklärender Code" ist kein eindeutiger Anspruch. Aus meiner Sicht gehört (natürlich Übung damit und) vor allem auch Professionalität und Virtuosität dazu.
Für die einen sind selbsterklärende Variablennamen wichtig, für die anderen eher a,b,c (bzw. i++). Das ist aber letztlich auch eine Frage der Codegestaltung selber.

Ein komplexer Algorithmus oder eine Funktion mit Schleifenverschachtelung und Variablenverschattung muß nicht gerade sehr übersichtlich sein.

Bei vielen Funktionen können alle Module einzeln getestet werden und auch woanders weiterverwendet, und so in den tieferen oder höheren Codezeilen kurz dokumentiert.

Bei Haskell gibt es viele interessante, aber (weil experimentell?) undokumentierte Funktionssammlungen. Das ist die reinste Pest, erschwert das schnelle Einarbeiten oder Überblicken und mindert generell den Bibliotheksstandard. Die Strategie ist dann, dass man eher nach Typen schaut (die ordentlich coden und dokumentieren) als nach Funktionen/Programmen. Die schlechte Übersicht mindert allein nicht den professionellen Anspruch, aber sie ist wichtiger Teil des Problems.

hustbaer

92 schrieb:

Für die einen sind selbsterklärende Variablennamen wichtig, für die anderen eher a,b,c (bzw. i++). Das ist aber letztlich auch eine Frage der Codegestaltung selber.

Was bitte könnte jemals das Argument für Bezeichner wie "a,b,c" sein? WTF? Natürlich sind sprechende Namen wichtig -- ganz egal ob Variablennamen oder sonstige Bezeichner.
i als Schleifenzähler bzw. allgemein anerkannte und verstandene Kurzform von "Index" ist OK. Ist aber auch so ziemlich der einzige 1-Buchstabenname der OK ist.

92 schrieb:

Ein komplexer Algorithmus oder eine Funktion mit Schleifenverschachtelung und Variablenverschattung muß nicht gerade sehr übersichtlich sein.

Weswegen tief verschachtelte Schleifen in einem vernünftigen Programm auch nix verloren haben. Kann man ja schliesslich leicht vermeiden.
Und auch komplexe Algorithmen kann man meist so implementieren dass zumindest jemand der den Algorithmus kennt und verstanden hat das Programm relativ leicht lesen kann. Und dass jemand der den Algorithmus und nicht versteht zumindest immer noch weiss was abgeht, welcher Algorithmus überhaupt verwendet wird und wo die Implementierung dieses Algorithmus anfängt und aufhört.

Mechanics

hustbaer schrieb:

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

Was ist mit x, y?

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.

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.