Variablen -> Guter Programmierstil

[Konrad Rudolph]

Chris++ schrieb:

Konrad Rudolph schrieb:

Simon2 schrieb:

Langer Rede kurzer Sinn:

O.o Ich glaube, das ist gerade das erste Mal, dass ich diesen Ausdruck korrekt geschrieben in einem Forum gesehen habe.

Wie soll man den Ausdruck sonst schreiben? oO

Die wohl am meisten verwendete Form scheint „Lange Rede, kurzer Sinn“ zu sein. (Womit der Sinn ein ganz anderer wäre.)

[*/*/*/]

Ja der gute alte Genitiv

[Simon2]

Konrad Rudolph schrieb:

Simon2 schrieb:

Langer Rede kurzer Sinn:

O.o Ich glaube, das ist gerade das erste Mal, dass ich diesen Ausdruck korrekt geschrieben in einem Forum gesehen habe.

Es hat auch ziemlich gedauert, bis ich diese Redewendung richtig begriffen hatte - nun MUSS ich sie einfach richtig schreiben.

Gruß,

Simon2.

[Chris++ 0]

[OT]

wie war das doch gleich mit dem Genitiv?

F: "Wessen Rede kurzer Sinn?"
A: "Langer"

naja keine Ahnung. Um ehrlich zu sein hab ich auch nur "Lange Rede kurzer Sinn" gelesen und war ein bisschen von Konrads Aussage überrascht.

[/OT]

[Simon2]

hustbaer schrieb:

Konsequent sein ist relativ einfach, und zwar schreibt man vor Datenmember einer Klasse m_.
Vor Funktionsmember NICHT.

Allzu konsequent finde ich das aber nicht, weil ich eigentlich keinen großen Unterschied zwischen beiden sehe (was spätestens bei einem Funktor als Datenmember offensichtlich wird) ...

Außerdem soll doch die Kennzeichnung (wenn ich recht informiert bin) eigentlich Klarheit darüber bringen, welches "Ding" genommen wird: Ist das bei Funktionsmember weniger wichtig als bei Datenmembern ?

Ich persönlich denke, es gibt in C++ sooo viele "Auflösungsmechanismen", dass eine Kennzeichnung dem eigentlich Ziel der Flexibilisierung mit so einer Kennzeichnung entgegengewirkt wird ... ebenso wie eine ständige Verwendung von "this->" oder "std::" ...
Sagen wir mal so: Wenn der Compiler weiß, welches Symbol wird, sollte ich das eigentlich auch wissen - und wenn er kein "m_" braucht, sollte ich das eigentlich auch nicht.

Gruß,

Simon2.

[Konrad Rudolph]

Simon2 schrieb:

Ich persönlich denke, es gibt in C++ sooo viele "Auflösungsmechanismen", dass eine Kennzeichnung dem eigentlich Ziel der Flexibilisierung mit so einer Kennzeichnung entgegengewirkt wird ...

Man *braucht* die Kennzeichnung aber nunmal, um Namenskonflikte zu vermeiden (Beispiel siehe unten). Und wenn man diese Kennzeichnung für einige Datenmember hat, sollte man sie konsequenterweise für *alle* fortsetzen.

class test {
    size_type length;

public:
    size_type length() const { return length; }
};

=> Kompilierfehler.

[Simon2]

Aber da geht's Dir doch gar nicht um die Unterscheidung zwischen Membern und Nicht-Membern, sondern um die Unterscheidung der Member untereinander.
Dasselbe Problem hättest Du mit

class test {
   size_type m_length;
   int m_length;
};

Gruß,

Simon2.

[C++ Forumbot]

Dieser Thread wurde von Moderator/in HumeSikkins aus dem Forum C++ in das Forum Rund um die Programmierung verschoben.

Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

Dieses Posting wurde automatisch erzeugt.

[Konrad Rudolph]

Simon2 schrieb:

Aber da geht's Dir doch gar nicht um die Unterscheidung zwischen Membern und Nicht-Membern, sondern um die Unterscheidung der Member untereinander.

Ja, natürlich. Der einzige und alleinige Zweck meiner Datenmember-Kennzeichnung ist die Auflösung von Namenskonflikten. Und solange mir da niemand einen besseren Vorschlag unterbreitet, mache ich es weiterhin so.

[Simon2]

Konrad Rudolph schrieb:

Simon2 schrieb:

Aber da geht's Dir doch gar nicht um die Unterscheidung zwischen Membern und Nicht-Membern, sondern um die Unterscheidung der Member untereinander.

Ja, natürlich. Der einzige und alleinige Zweck meiner Datenmember-Kennzeichnung ist die Auflösung von Namenskonflikten....

OK, dann ist das aber eine andere Zielrichtung als die oben angesprochene.
Das bedeutet mit

class test {
    size_type length;

public:
    size_type getLength() const { return length; }
};

hättest Du auch keine Probleme ...

Gruß,

Simon2.

[Konrad Rudolph]

Simon2 schrieb:

Das bedeutet mit

class test {
    size_type length;

public:
    size_type getLength() const { return length; }
};

hättest Du auch keine Probleme ...

Klar, aber diese Lösung finde ich absolut inakzeptabel. Erstens ist sie nicht konform mit der Konvention aus der Stdlib/Boost und zweitens mag ich sie nicht.

[asc]

Konrad Rudolph schrieb:

Simon2 schrieb:

...

size_type getLength() const { return length; }

...

Klar, aber diese Lösung finde ich absolut inakzeptabel. Erstens ist sie nicht konform mit der Konvention aus der Stdlib/Boost und zweitens mag ich sie nicht.

Aber sie hat einen Vorteil: Man liest was die Funktion macht. Wenn ich eine Funktion length nenne kann das etliches bedeuten: Setze ich nun die Länge, lese ich sie, oder was mache ich sonst damit.

Sprechende Bezeichungen können auch Methoden gebrauchen. Wobei ich gestehe das mir persönlich in diesem Fall die Property-Schreibweise von C# besser gefällt.

cu André

[Konrad Rudolph]

asc schrieb:

Sprechende Bezeichungen können auch Methoden gebrauchen. Wobei ich gestehe das mir persönlich in diesem Fall die Property-Schreibweise von C# besser gefällt.

Natürlich, ne Property wäre das Optimum. Aber das löst das Problem nicht, man hätte immer noch den Namenskonflikt.

[rüdiger]

Benutzt einfach Bezeichner, die leserlich und gut zu merken sind. (Und ich bezweifel mal, das merkwürdige (Einbuchstaben-) Kürzel oder wahllose gesetzte Unterstriche am Anfang/Ende der Lesbarkeit nicht helfen).

ichBinGast schrieb:

1. int var_ = ...;
2. int _var = ...;
3. int __var = ...;

3. ist vom C++ Standard her dem Compiler vorenthalten! Und 2) im globalen Namespace AFAIK auch. Aber findest du das wirklich schön/leserlich?

Macht es sinn für pointer so was zu machen:

1. p_shift = ...;
2. ptr_shift = ...;

Nein.

[Konrad Rudolph]

rüdiger schrieb:

(Und ich bezweifel mal, das merkwürdige (Einbuchstaben-) Kürzel oder wahllose gesetzte Unterstriche am Anfang/Ende der Lesbarkeit nicht helfen).

Also, wenn ich einen gutdokumentierten Pseudocode implementiere, finde ich es allgemein besser, die Ein-Buchstaben-Kürzel aus diesem Pseudocode zu übernehmen und dann in einem Kommentar eine Quellenangabe (bzw. Verweis auf die Doku) zu schreiben, anstatt mir möglicherweise irreführende Bezeichnernamen aus den Fingern zu saugen.

[Jockelx]

Konrad Rudolph schrieb:

Simon2 schrieb:

Langer Rede kurzer Sinn:

O.o Ich glaube, das ist gerade das erste Mal, dass ich diesen Ausdruck korrekt geschrieben in einem Forum gesehen habe.

OT: Ohne da wirklich Ahnung von zu haben, so lieferte mit der erste Google-Treffer
eine Diskussion über Schiller, die folgendes feststellt:

'Als falsch kann keine der beiden Formen bezeichnet werden, da "Lange Rede, kurzer Sinn" eine durch ein Komma segmentierte Aufzählung darstellt, die inhaltlich mit "langer Rede kurzer Sinn" übereinstimmt.'.

Sehe da auch keinen Unterschied.

Jockel

[Shade Of Mine]

Konrad Rudolph schrieb:

Natürlich, ne Property wäre das Optimum. Aber das löst das Problem nicht, man hätte immer noch den Namenskonflikt.

das problem mit "nur um namenskonflikte aufzulösen" ist, dass man dabei inkonsistent wird.

ein public member: hat der nun eine kennzeichnung oder nicht? eigentlich nicht, weils ja hässlich ist - aber im prinzip müsste er eine haben. diese trennung public/private interface führt zu vielen solcher situationen.

vec.m_x - ist einfach nur bullshit. sowas kann man keinem programmierer antun, m_x muss deshalb x im public interface heissen.

das problem warum es überhaupt zu konflikten kommt, ist in der STL namenskonvention begründet. jede andere konvention hat diese probleme nicht.

in Java habe ich

public int getLength() {
  return length;
}

in C# habe ich

public int Length {
  get {
    return length;
  }
}

etc.

manchmal macht man sich probleme selber

[Konrad Rudolph]

Shade Of Mine schrieb:

das problem warum es überhaupt zu konflikten kommt, ist in der STL namenskonvention begründet. jede andere konvention hat diese probleme nicht.

in C# habe ich

public int Length {
  get {
    return length;
  }
}

Das ist ebenfalls inakzeptabel. Die Verwechslungsgefahr aufgrund kleiner/großer Buchstaben ist viel zu hoch und stellt eine subtile, schwer findbare Fehlerquelle dar (wenn in der Property z.B. noch Konsistenzprüfungen vorgenommen werden). Daher gilt für mich persönlich und auf Arbeit auch die eiserne Regel, dass Bezeichner im selben Scope nie allein durch die Groß/Kleinschreibung unterschieden werden dürfen.

[Shade Of Mine]

Konrad Rudolph schrieb:

Das ist ebenfalls inakzeptabel.

und dennoch ist es industrie standard.

Die Verwechslungsgefahr aufgrund kleiner/großer Buchstaben ist viel zu hoch und stellt eine subtile, schwer findbare Fehlerquelle dar (wenn in der Property z.B. noch Konsistenzprüfungen vorgenommen werden).

nein. es liefert dir einen compiler fehler, mehr nicht.

Daher gilt für mich persönlich und auf Arbeit auch die eiserne Regel, dass Bezeichner im selben Scope nie allein durch die Groß/Kleinschreibung unterschieden werden dürfen.

schön für dich. aber man sollte immer alle facetten bedenken. zum beispiel hast du eine inkonsistente namensgebung. sei es nun m_x oder x_. m_x hat eine menge eigener probleme deshalb gehe ich mal von x_ aus. hier hat man wieder nur 1 zeichen unterschied zwischen size() und size_. Ist das viel besser als size und Size?.

[Jockelx]

Shade Of Mine schrieb:

Die Verwechslungsgefahr aufgrund kleiner/großer Buchstaben ist viel zu hoch und stellt eine subtile, schwer findbare Fehlerquelle dar (wenn in der Property z.B. noch Konsistenzprüfungen vorgenommen werden).

nein. es liefert dir einen compiler fehler, mehr nicht.

Soweit ich weiss liefert dich z.B.

public int Length {
  get {
    return Length;
  }
}

keinen compiler Fehler, sondern eine endlos Rekursion.
Was allerdings nicht heissen soll, dass ich diese Konvention in C# ablehne.

Jockel