Ungarische Notation? ja oder nein?

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.

Marc++us

Bashar schrieb:

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.

Nope.

Eine Property kann durchaus auch "calculated" sein - nur der Name der Property muß festgelegt werden.

Aber zu dem Namen der Property ist nur festgelegt, daß es getter/setter gibt, nicht deren Implementation:

class Foo  // C#
{
   private int m_x;
   private int m_y;
   public int area
   {
      get
      { 
         return m_x * m_y;
      }
   }
}

Damit führt

Foo foo = new Foo();
int x = foo.area;

zum Aufruf der Methode get, deren Implementation aber freigestellt ist - sie könnte auch return 0 machen.

Beim Builder bin ich mir darüber aber nicht zu 100% sicher, ob das genauso gemacht wurde.

Helium

Also ich schließe mich Kingruedi an. Ein Suffix oder für die Englisch-Liebenden auch postfix bei Member-Variablen macht durchaus sinn und wird von mir auch konsequent umgesetzt. Da tatsächlich alle diese Variablen das selbe kürzel verwenden wäre sogar ein Präfix, wie das häufig verwendete m_ kein problem. Die Variablen lassen sich immernoch problemlos nach den selben Kriterien sortieren. Das ist ja mitunter auch ein Kritikpunkt an der uN.

volkard

SeraDelta3 schrieb:

Hi,
glaubt ihr die Ungarische Notation braucht man in C++ noch oder ist sie total veraltet?
Wie denkt ihr drüber?

total veraltet.

Blue-Tiger

ich persoenlich steh da momentan vor einem Problem:

bis vor einem Jahr hab ich Visual Basic programmiert (shame on me ), hab dann C++ gelernt und Konsolen-Programme geschrieben. Bei VB hab ich durchgehend UN benutzt, wie in VB eben ueblich, unter C++ hab ich's mir angewoehnt.

Aber jetzt, wo ich langsam anfange, mich in GUI-Libs einzuarbeiten, stehe ich vor dem Problem: wie benenn ich meine Steuerelemente. Bei normalen Variablen brauch ich kaum UN, die sind meistens lokal, werden also nur in kurzen Code-Abschnitten eingesetzt. Es ergibt sich quasi aus dem Kontext (bzw. dem restlichen Namen - z. B. ist es offensichtlich, dass "counter" irgend ein Integer ist), welchen Typ eine Variable hat...

bei den Steuerelementen ists nicht so (IMO), und ich faends manchmal ganz nuetzlich zu wissen, was nun ein Textfeld, was ein Label usw. ist... wie benennt ihr eure Steuerelemente?

Marc++us

Ich benenne in Dialogen die Elemente so, wie sie sind - das erscheint mir am natürlichsten:

radioUser
chkboxFile
editUsername
dlgWarning

Das ist aber durchaus noch C++-üblich und hat nichts mit der UN zu tun.

In C++ ist es ja gängig, daß der Objektname auch mal was mit dem Klassennamen zu tun hat:

Car myRedCar;

usw. - UN heißt, daß man ein Prefix, das eine Abkürzung des Typs darstellt, voranstellt. Verzicht auf UN bedeutet nicht, daß man aus dem Objektnamen nicht mehr den Klassennamen oder die Familienzugehörigkeit erkennen darf/kann.

Shade Of Mine

Marc++us schrieb:

Nope.

Eine Property kann durchaus auch "calculated" sein - nur der Name der Property muß festgelegt werden.

Aber zu dem Namen der Property ist nur festgelegt, daß es getter/setter gibt, nicht deren Implementation:

Oh, OK danke!
dann habe ich nur mehr n bisschen was gegen properties...