Variablen -> Guter Programmierstil

[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

[Konrad Rudolph]

Shade Of Mine schrieb:

Konrad Rudolph schrieb:

Das ist ebenfalls inakzeptabel.

und dennoch ist es industrie standard.

Ach Quatsch. Wo ist es Industriestandard? In „der Industrie“ gibt es endlos viele Standards. Microsoft selbst verwendet intern mehrere verschiedene Konventionen (darunter den führenden Unterstrich sowie das Präfix 'm_', letzteres ziemlich durchgängig in der aktuellen Implementierung des .NET-Frameworks).

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.

Eben nicht. Es wird *gar kein* Fehler geliefert, siehe folgenden Code:

class Withdrawal {
    private readonly int accountBalance;
    private int amount;

    private int AccountBalance { get { return accountBalance; } }

    public int Amount {
        get { return amount; }
        set {
            if (value > accountBalance)
                throw new OverflowException("Es kann nur soviel Geld abgehoben werden, wie sich auf dem Konto befindet.");
            amount = value;
        }
    }

    public Withdrawal(int accountBalance) {
        this.accountBalance = accountBalance;
    }

    public void Perform(int amount) {
        this.amount = amount; // Ups, falsches Member!
        // Transaktion durchführen.
    }
};

// Und jetzt folgender Aufruf:

int meinKontoStand = 1000;
Withdrawal ichWillMehr = new Withdrawal(meinKontoStand);
ichWillMehr.Perform(2000); // Jetzt wird die Bank um 1000 EUR betrogen.

Solch ein Fehler ist übrigens *nicht* rein akademisch sondern ein reell auftretendes Problem.

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.

Nein, meine Namensgebung ist konsistent. Ich sehe zumindest keine Inkonsistenz. Fürs Protokoll: Ich verwende momentan durchgängig 'm_' als Präfix, auf Arbeit ist Präfix-'_' Konvention.

[Jockelx]

Da verstehe ich das Problem nicht. Dem Member wird einfach ein Wert zugewiesen,
ohne vorher eine Prüfung vorzunehmen. Das kann dir mit jeder anderen Konvention
doch auch passieren. Wenn man die Konvention gewohnt ist, sieht man sofort,
dass da halt nicht der Setter genommen wird, sondern direkt das Member.

[Konrad Rudolph]

Jockelx schrieb:

Wenn man die Konvention gewohnt ist, sieht man sofort,
dass da halt nicht der Setter genommen wird, sondern direkt das Member.

Hm. Ich halte diese Unterscheidung für quasi-nichtexistend. Es gab dazu irgendwo mal nen netten Blog-Artikel: Da wir Menschen gewohnt sind, dass sich die Bedeutung eines Wortes generell nicht sehr verändert, wenn wir die Groß-/Kleinschreibung verändern, überlesen wir solche Änderungen sehr häufig. Ich halte diese Argumentation für plausibel und kann ihr aus eigener Erfahrung auch zustimmen. Außerdem vergisst man schnell mal, ne Shift-Taste zu drücken. Aber aus Versehen 'm_' zu tippen, das passiert glaube ich niemandem.

– Ich sehe hier definitiv ein großes Gefahrenpotential. Aber selbst wenn andere das für nicht so groß halten: Es lässt sich so *einfach* eliminieren.

[Jockelx]

Gut, mag sein. Ich nutze C# nur privat und in kleinen, übersichtlichen Projekten.
Deshalb kann ich vielleicht nicht so super mitreden. Aber zumindest da hatte
ich nie Probleme die Getter/Setter von den Membern mit dieser Konvention zu unterscheiden.

Jockel

[Shade Of Mine]

Konrad Rudolph schrieb:

Hm. Ich halte diese Unterscheidung für quasi-nichtexistend. Es gab dazu irgendwo mal nen netten Blog-Artikel: Da wir Menschen gewohnt sind, dass sich die Bedeutung eines Wortes generell nicht sehr verändert, wenn wir die Groß-/Kleinschreibung verändern, überlesen wir solche Änderungen sehr häufig.

und

this.accountBalance = accountBalance_;

schreit nach einem fehler?

– Ich sehe hier definitiv ein großes Gefahrenpotential. Aber selbst wenn andere das für nicht so groß halten: Es lässt sich so *einfach* eliminieren.

ich sehe zwischen a und a_ nicht viel unterschied. das problem ist: will ich hier setter verwenden oder nicht? ich will eigentlich fast nie intern die checks eines set-properties haben. maximal in einem ctor. aber um ehrlich zu sein, ich weiss nicht wann ich das letzte mal einen setter hatte der mehr gemacht hat als dumme zuweisung.

und erklär mir nochmal den großen vorteil von
this.a = a_;
gegenüber
this.a = a;
ich habs nicht ganz verstanden.

[Konrad Rudolph]

Shade Of Mine schrieb:

und erklär mir nochmal den großen vorteil von
this.a = a_;
gegenüber
this.a = a;
ich habs nicht ganz verstanden.

Musst Du auch nicht, ich finde den Unterschied auch nicht deutlich genug. Daher verwende ich auch 'm_' als Präfix. Dort ist der Unterschied allemal deutlich.

[Shade Of Mine]

Konrad Rudolph schrieb:

Musst Du auch nicht, ich finde den Unterschied auch nicht deutlich genug. Daher verwende ich auch 'm_' als Präfix. Dort ist der Unterschied allemal deutlich.

das bringt aber ein enormes intellisense problem mit sich: intellisense fast nutzlos. das schränkt die produktivitaet ein.

weiters gibt das selbe argument wie bei groß/kleinschreibung:
der mensch erkennt ein wort anhand der ersten paar buchstaben. bzw, die ersten paar buchstaben sind signifikant.

das ist zB ein grund warum gross/kleinschreibung wieder halbwegs funktioniert, weil der 1. buchstabe das ist was du als erstes erkennst

[Konrad Rudolph]

Shade Of Mine schrieb:

Konrad Rudolph schrieb:

Musst Du auch nicht, ich finde den Unterschied auch nicht deutlich genug. Daher verwende ich auch 'm_' als Präfix. Dort ist der Unterschied allemal deutlich.

das bringt aber ein enormes intellisense problem mit sich: intellisense fast nutzlos. das schränkt die produktivitaet ein.

Inwiefern? Kann ich nicht nachvollziehen. (Ich greife ja nur aus der Property selbst auf das Feld zu).

der mensch erkennt ein wort anhand der ersten paar buchstaben. bzw, die ersten paar buchstaben sind signifikant.

das ist zB ein grund warum gross/kleinschreibung wieder halbwegs funktioniert, weil der 1. buchstabe das ist was du als erstes erkennst

Aha … das erzählst Du mir in einem C++-Form … alles klar.

– Du hast ja recht. Aber ein durch '_' getrenntes Präfix kann man für sowas ziemlich gut „ausblenden“.

Siehe auch: http://dotnet.mvps.org/dotnet/articles/camelcase/

Der Artikel bringt das ziemlich gut auf den Punkt und ist m.E. der beste zu diesem Thema.