Ungarische Notation? ja oder nein?

Hi,

glaubt ihr die Ungarische Notation braucht man in C++ noch oder ist sie total veraltet?

Wie denkt ihr drüber?

Marc++us

Für C++ war sie ohnehin nie wirklich gedacht und ist dafür völlig ungeeignet. Aber warte ab... dieser Thread wird in 3 Tagen 10 Seiten haben.

Morgen wird die Suchfunktion wieder funktionieren, dann kannst Du die alten Diskussionen dazu nachlesen.

ChrisM

/me sieht den Flamewar schon kommen.

Also, ich halt nicht viel von der ungarischen Notation, vor allem in den Zeiten, wo man dank intelligenter IDEs eigentlich auch ohne das p sieht, was z.B. ein Zeiger ist und ohne das f, was ein float ist.

Trotzdem verwende ich im Moment aus Gründen der Einheitlichkeit noch m_, g_, p, f, n und ch, weil ich damit angefangen habe und zu faul bin, jetzt überall im Projekt die Namen zu ändern.

ChrisM

uN war eigentlich für WinAPI gedacht. Bei C++ hat das wenig zu suchen. C++ ist sowieso unleserlich, egal wie man das angeht. Alleine die set/get-methoden führen zum blödsinnigen set_x_Wert(int x){m_x = x;};
Da ist nichts mehr zu retten, aber bei C/WinAPI ist die uN o.k., weil Quasistandard.

Bashar

Du musst ja deine Methoden nicht so bescheuert nennen.

also so ne bescheuerte Funktion hab ich nie mals gesehen:

set_x_Wert(int x){m_x = x;};

total bekloppt, also wer sowas macht gehört erschossen! Nebenbei ich find C++ code irgendwie leichter zu lesen als ANSI C Code

Knuddlbaer

Was spricht denn gegen set_<Name>() oder get_<Name>

Allemal besser als SetName und GetName ;o)

Shade Of Mine

dem ist nix hinzuzufügen

UN hat sich einfach überholt.

ob set_name
oder setName
oder SetName
oder Set_Name
oder set_Name

ist doch nun wirklich egal.

@ChrisM:
wofür stehen denn f, n und ch?

Taurin

Shade Of Mine schrieb:

wofür stehen denn f, n und ch?

f Fließkommazahlen
n Ganze (natürliche ?) Zahlen
ch Chars

Glaub ich jedenfalls, mich zu erinnern...

rüdiger

auch wenn es langsam OT wird

ich nehm weder getName setName oä., dass set und get kann man sich ja dank Funktionsüberladung sparen

class demo {
  int foo_m;
public:
  inline demo(int f) : foo_m(f) { }
  inline int foo(void) const { return foo_m; }
  inline void foo(int f) { foo_m=f; }
};

Hm, ich finde sie durch aus nützlich für die Basistypen, wie int, float etc.
Aber wie machen wir das bei Objekten ? Da knallt es, weil die UN nie dafür vorgesehen war.
wir könnten nun sagen wir schreiben ein o für objekt, und dann irgend was was
sagt was das für ein objekt ist. Nur kann sich das keiner merken, und wäre
somit schwachsinn.

Imho für C sinnvoll, aber für C++ ungeignet, abgesehen von basistypen.

Devil

Knuddlbaer

@Kingru

Wie ist das wenn jemand den Code warten soll....

ist bool print(); nun eine Methode die was ausgibt oder eine Methode die zurückgibt ob das Objekt gedruckt werden darf ? setName set_Name is schon doof zu lesen, aber so weiß man garnicht mehr was sache ist?!

Shade Of Mine

devil81 schrieb:

Hm, ich finde sie durch aus nützlich für die Basistypen, wie int, float etc.

in C++ ist es egal ob
count
vom type int oder Int ist.

es ist doch egal was dahinter steckt...
du schreibst

i=3;
cout<<i;
und weisst, das 3 ausgegeben wird. egal ob da ein builtin oder eine klasse dahinter steckt...

Patsch

ist bool print(); nun eine Methode die was ausgibt oder eine Methode die zurückgibt ob das Objekt gedruckt werden darf ?

Das beantwortet UN auch nicht. Das beantwortet nur eine Quickreferenz, die nach wie vor nicht zum Standard eines Entwicklungssystems gehört - den gibt es nämlich nicht. Wenn sich da etwas mehr tun würde, wären diese hirnrissigen Prä- und Postfixes auch total überflüssig. Für meine Begriffe sind striktere Warnungen bei impliziten Typenumwandlungen viel hilfreicher als jegliche Notation.

PeterTheMaster

bei dem printbeispiel ging es nicht um UN, sondern darum, ob es getPrint oder print heissen sollte. ich bin fuer ersteres.

Bashar

mein Vorschlag: print_flag
getPrint sagt nämlich auch nix aus ("hole Ausdruck" aha)

Marc++us

Ich denke, daß die Prefixes für Methodennamen set, get, is so weit eingeführt sind, daß man sie auch verwenden sollte. Vor allem auch vor dem Hintergrund, daß Spracherweiterungen wie beim C++-Builder oder auch neue Sprachen wie C# für die Properties darauf zurück greifen. Auch viele UML-Tools mit den Codegeneratoren erzeugen diese Prefixes automatisch.

Gregor

...und ich bin dafür, dass eine Variable nicht print heißt, somit bin ich also gegen getPrint und auch gegen print.

-> keine Verben als Variablennamen.

ist bool print(); nun eine Methode die was ausgibt oder eine Methode die zurückgibt ob das Objekt gedruckt werden darf ?

Das ist ne Methode, die etwas ausgibt. Ansonsten vollkommen falsch benannt, da mißverständlich. "bool isPrintable()" wäre sonst besser.

Bashar

die get- und set-Namensgebung impliziert, dass dort direkt "dumme" Variablen dahinter hängen. Wenn man ein Objekt in erster Linie als Kapselung von Verhalten auffasst, passt das nicht mehr. Ausserdem verleitet es dazu, ohne nachzudenken für alle möglichen Felder pauschal Getter und Setter zu implementieren.

Ein IMHO ziemlich gelungenes Beispiel hat man beim vektor-Template: statt get/set_capacity heißen die entspechenden Funktionen reserve und capacity.

Wenn ich was zu sagen hätte, würd ich vorschlagen, Properties in den Standard aufzunehmen, aber ohne dass diese tatsächlich vorhandene Felder kapseln müssen.

(BTW hatte ich das mit dem print falsch verstanden (dass das Objekt gedruckt werden soll statt kann), demzufolge ist natürlich printable ein besserer Name.)

rüdiger

hmm, Bashar und Gregor haben dazu eigentlich schon alles gesagt, aber noch ein kleiner Nachsatz von mir

bool print();

wenn man sich mal absolut nicht sicher ist, kann man ja immer noch die Doku zur Rate ziehen. (btw. würde ich hier eh kein bool zurückgeben. Wenn print fehlschlägt, dann fliegt eben eine Exception und void print(void) const ist doch sehr verständlich, vorallem wenn man noch ein std::ostream Argument übergibt (ich will ja niemanden vorschreiben auf den Bildschirm malen zu müssen ;)) void print(std::ostream &out) const; Also ich denke nicht, dass ich in meinen Programmen Access-Methoden habe, die jemand mit anderen Methoden verwechseln könnte, vielleicht hast du einen anderen Programmierstil, wo dies durchaus passieren kann)

<edit>hmm, [code type="c++"] geht wohl nicht mehr, da muss ich mich wohl umgewöhnen ;)</edit>