Ungarische Notation? ja oder nein?

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>

Helium

Wie oft kommt es bei euch denn vor, dass direkt irgendwelche Variablen der Objekte direkt manipulieren müsst. Bei euch scheint das ja eher die Regel, als die Ausnahme zu sein. Irgendwas macht ihr da falsch.

keine Verben als Variablennamen.

Wie gut das das keiner gemacht hat, da print auch der Druck ist.

[cpp]
class Bla
{
public:
int a(void) const
{
return m_a;
}

void a(int a)
{
m_a = a;
}

private:
int m_a;
};

So habt ihr das get, set nicht mehr
Ungarische Notation bedeutet aber auch das mit dem m_, aber bei mir kommt es ohne diesen m_ oft zu Namenskonflikten. Wie sollte man das denn fein lösen?

Bashar

@Unregistrierter: Denk ich nicht. Die ungarische Notation hat die Präfixe ja nicht gepachtet. UN ist doch nur, dass man jeder Variable ein Typpräfix verpaßt, und das auch noch nach der Konvention die dieser Ungar bei MS sich ausgedacht hat.

Knuddlbaer

Hmm.... Irgendwie hat Bashar und Helium recht....

Wenns schnell gehen muß neigt man zu schnell einfach set und get zu verwenden. Das Beispiel mit dem vector war gut, das regt zum grübeln an. Irgendwie hab ich zu viel Basic damals programmiert

Das Forum bringt einen doch immer wieder weiter....

thx

tag

Anonymous schrieb:

Ungarische Notation bedeutet aber auch das mit dem m_, aber bei mir kommt es ohne diesen m_ oft zu Namenskonflikten. Wie sollte man das denn fein lösen?

class Bla 
{ 
public: 
 void foo(int a) 
 { 
  Bla::a = a; 
 } 

private: 
 int a; 
};

Allerdings lässt sich dann natürlich nicht mehr eine Methode a einfügen...

Shade Of Mine

this->a=a;

wo liegt das problem?

ich denke nicht, dass es sinn macht um namenskonflikte zu vermeiden einen namen zu verunstalten...

weiters stimme ich bashar mit den gettern und settern zu (deshalb bin ich auch gegen properties)

es gibt aber auch situationen wo getter und setter sinn machen:
Windows::SetTitle()
ist zB durchaus sinnvoll

rüdiger

also ich finde ein _m Postfix bei Daten Membern ist sinnvoll. Erstens haben dann die Member die gleichen Namen wie die set/get Methoden (+ _m) und man erkennt sofort was ein Member ist, was bei etwas größeren Funktionen schon nützlich ist. Außerdem kann man den Parametern gleich sinnvolle Namen geben.

(und _m bzw _ als Postfix ist eigentlich auch sehr populär. Herb Sutter nutzt zB. _ als Postfix für Member)

Bashar

Shade Of Mine schrieb:

weiters stimme ich bashar mit den gettern und settern zu (deshalb bin ich auch gegen properties)

Was hat das eine mit dem anderen zu tun?

Shade Of Mine

Bashar schrieb:

Shade Of Mine schrieb:

weiters stimme ich bashar mit den gettern und settern zu (deshalb bin ich auch gegen properties)

Was hat das eine mit dem anderen zu tun?

uU habe ich properties falsch verstanden...
so habe ich sie verstanden:

statt
foo.setA(bar);
schreibt man
foo.a=bar;
und ruft intern eine set-Methode auf.

oder kann man properties auch verwenden wenn die klasse garkeinen member mit namen a hat??

wenn ich properties richtig verstanden habe, sind sie auf existierende variablen bezogen. insofern sollte klar sein warum ich etwas dagegen habe.

wenn ich sie falsch verstanden habe, dann bitte berichtigen.

@kingruedi:
ich verwende keine besondere kennzeichnung für member variablen.
so sieht zB ein ctor aus:

Klasse::Klasse(int size) : size(size) {}

bei anderen sachen funktioniert es auch... notfalls muss man halt ein this-> schreiben, stört aber nicht besonders wie ich finde.

also eine notwendigkeit ist sicher nicht da - aber wenn es jemand macht soll es mich nicht stören. ich will nur klarstellen, dass es kein muss ist.

Bashar

Shade Of Mine schrieb:

wenn ich properties richtig verstanden habe, sind sie auf existierende variablen bezogen. insofern sollte klar sein warum ich etwas dagegen habe.

Ach so. Ich glaube du hast Recht, aber ich verstehe den Begriff verallgemeinernd auch so, dass die Variable dahinter nicht unbedingt existieren muß. Im BCB und in C# muß sie meines Wissens leider da sein, was den Nutzen ziemlich einschränkt, IMHO.

notfalls muss man halt ein this-> schreiben, stört aber nicht besonders wie ich finde.

Ja schon, Kollisionen mit Argumenten kann man vermeiden. Aber Kollisionen mit Memberfunktionen nicht. Beispiel aus dem Stroustrup:

class Date {
  int d, m, y;
public:
  Date(int dd, int mm, int yy): d(dd), m(mm), y(yy) { }
  int day() const;
  int month() const;
  int year() const;
};

Er hat 3 verschiedene Namen für den gleichen Begriff. Einer davon läßt sich einsparen, aber es wird immer Kollisionen zwischen Memberfunktion und -variable geben.