Nochmal: Ungarische Notation

Mis2com

Hi,

ich sehe noch einiges, was bei ungarischer Notation nützlich ist.
Z.B. was, wenn man jetzt Folgendes hat:

float foo;

das hier ist nicht f(für float)oo ;).

Jedenfalls sollte man später jetzt ja sagen foo = 0.0f und nicht foo = 0, oder?
Wenn dem so ist, dann ist es doch sehr praktisch, wenn man, was man angeben soll, daran erkennen kann. Die C++-Klassen haben zwar die Möglichkeiten sie so zu machen, dass man sie möglichst nicht von einfachen Datentypen unterscheiden kann, aber auch da gibt es keine einheitliche Schreibweise für z.B. 0. (korrigiert mich, wenn dem doch so ist)
Genauso sieht es mit String und C-Strings aus, wenn man Letzteres verwendet ist z.B. ein Vergleich mit == nicht möglich.
Gerade für Außenstehende, die den Code nicht kennen, ist sowas doch enorm hilfreich!?
Natürlich halte ich von C bei Klassen nicht viel, ich nutze m_ und p, aber nur etwas verwenden, weil die IDE z.B. . zu -> macht oder einem den Typ anzeigt, das zählt für mich nicht, da man ja nicht automatisch erwarten kann, dass der Benutzer oder Warter des Codes auch so eine IDE hat.

Nagut, im Grunde will ich die Diskussion weiterführen, das stimmt, mir ist es halt nicht klar.

MfG Eisflamme

Jester

Wenn Du Deine Variablen immer schön lokal hältst, dann kannst Du den Typ immer gleich nachschauen, wenn Du ihn brauchst. Aber mal ehrlich, wie oft kommt es auf den exakten Typ an, und wie oft auf das Verhalten?

Mit == will ich vergleichen, dabei ist es mir egal, ob es ints floats oder strings sind. Leider fallen die C-Strings da aus dem Rahmen. => ich benutze sie nur, wenn ich unbedingt muß, und das ist sehr selten.

MfG Jester

Jover

Es heist ja, dass man den Scope einer Variable so kurz wie möglich machen soll. Deshalb kann man sich das auch merken, dass foo z.B.: vom Typ float ist.

Ansonsten würde ich den namen der Variable entsprechend informativ wählen.
m_ als Präfix für Membervariablen finde ich genauso unsinnig.

Mis2com

Hi,

nagut, das mit C-Strings stimmt.
Ganz lokal ist ja nicht immer gesagt, z.B. hat man ja auch größere Funktionen, bei denen man nicht immer wieder nach oben schauen muss... Naja, aber eigentlich definiert man Variablen ja auch erst dann, wenn man sie braucht, und wenn man sie oft braucht, dann nutzt man sie so oft, dass man es weiß.
Als Attribute können solche Variablen allerdings auch vorkommen, das kann man dann nachschauen, nagut, auch ok.
Tja, äh, aber dann wären Zeiger-Präfixe doch auch Quatsch, weil man das mit dem Zeiger auch schnell nachlesen kann?
Ich sehe darin allerdings insofern Sinn, als dass es nicht ein Hund ist, sondern nur ein Zeiger auf den Hund...
Frage ist jetzt natürlich, ob durch das * dieses Zeiger auf direkt mit zum Namen gehört, hm.

Noch was:
Ist es eigentlich schlechter Stil Monsterfunktionen zu machen, statt vielen vereinzelten, wenn man jeden Teil der Funktion ohnehin nur einmal benötigt, einzelne Abschnitte kommentiert und Variablen auch erst dann definiert, wenn sie nötig sind?
In meinem aktuellen Projekt habe ich so eine Funktion, es handelt sich direkt um main, also ich sehe da kein sonderlich großes Problem drin, aber es ist ja allgemein nicht besonders schön, oder?

MfG Eisflamme

Mis2com

@Jover:
Wie verhält es sich, wenn man einer Funktion Parameter übergibt, die, ein wenig verändert, dann als Klassenattribute weiterverwendet werden sollen?
Dann ist man ohnehin auf ein Präfix oder Suffix angewiesen.

Ob m_ ansich jetzt zur Übersichtlichkeit nötig ist, weiß ich noch nicht, darüber werde ich noch ein wenig nachdenken.

MfG Eisflamme

groovemaster

Mis2com schrieb:

Jedenfalls sollte man später jetzt ja sagen foo = 0.0f und nicht foo = 0, oder?

Ich denke nicht. Ich schreib entweder foo = 0 oder foo = 0.0. Was ist, wenn aus float irgendwann mal double wird. Dann musst du alle Literale nachschaun, ob durch das f Suffix nicht irgendwo unnötig Genauigkeit verloren geht (oder kann der Compiler das wieder wettmachen?).

Mis2com schrieb:

Wie verhält es sich, wenn man einer Funktion Parameter übergibt, die, ein wenig verändert, dann als Klassenattribute weiterverwendet werden sollen?

Genau deshalb ring ich mich immer mehr dazu durch, für Attribute das _ Suffix zu verwenden. Ich denke aber das hat nix mehr mit der ungarischen Notation zu tun. Schliesslich wird es nicht dazu verwendet, um im Namen Informationen zu verschlüsseln, sondern um Namenskonflikte zu vermeiden (btw. bin ich kein Freund von this->... wenn es nicht wirklich notwendig ist).

TheBigW

Ich oute mich -> ich mags auch ungarisch

Warum? Ganz einfach: wenn ein Projekt größer wird, dann kostet auch das bisschen nachschauen Zeit. Ich finde auch m_ für Member cool,da ich dann sofort weiß, das eine Änderung der Variablen irgendwie das Laufzeitverhalten der Klasse beeinflussen kann (so sie nochmal irgendwo verwendet wird). Sozusagen hilft mir das erstmal schnell die Relevanz vorzusortieren. Bei Fremdcode finde ich es auch Hilfreich. Gerade, wenn ich von mir ausgehe -> bin mit Kommentaren selbst meist etwas sparsam. Da Hilft mir die ungarische Notation doch auch nach längerer Ruhepause wieder zurecht zu kommen.

Jover

Mis2com schrieb:

@Jover:
Wie verhält es sich, wenn man einer Funktion Parameter übergibt, die, ein wenig verändert, dann als Klassenattribute weiterverwendet werden sollen?
Dann ist man ohnehin auf ein Präfix oder Suffix angewiesen.

Ob m_ ansich jetzt zur Übersichtlichkeit nötig ist, weiß ich noch nicht, darüber werde ich noch ein wenig nachdenken.

MfG Eisflamme

Wenn ich dich jetzt richtig verstehe meinst du sowas:

void Foo::setAValue(int value)
{
    this->value = value;
}

Hier braucht man auch kein Prä/Postfix, da man mit this auf die Membervariable value zugreifen kann. Der Aufruf über this-> ist auch nicht langsamer als ohne, also warum nicht?

Bei Konstruktoren ist das so ein Problem: Hier verwende ich für den übergebenen Parameter ein _ als Postfix, oder nenne den Parameter anders (meist abgekürzt aber trotzdem noch erkennbar).

SirLant

Ich verwende in MFC Projekten in gewissem Maße die ungarische Notation, der konsistenz
der Namen zu liebe.
Würde normale gerne ein C vor den Klassennamen weglassen, aber damit es einheitlich
ist schreibe ich ein C davor, außerdem verwende ich m_ als suffix für Member
einer Klasse, wo ich lieber nur _ benutzen würde, weil es einfacher zu schreiben
ist und man trotzdem sofort erkennt, dass es ein Member ist.

Sonst verwende ich eigentlich keine suffixe, temp-strings nenne ich meist "str"
was wohl jeder als string entziffern kann und sonstige Variablen, wie i oder j
weiß auch jeder, dass es sich um nen int handelt.
Sonst schaut man halt kurz nach, muss ich auch öfters in fremden Code bzw. mit
dem Cursor auf der Variable bleiben.

Ich denke, wenn man wirklich die Variablen so lokal wie möglich hält, was ja
keinerlei Nachteile bringt, eher im Gegenteil (spart Speicher, ist schneller
und man macht weniger Fehler), dann ist kurz nachzuschauen auch nicht zu viel
verlangt.

Shade Of Mine

Jover schrieb:

Bei Konstruktoren ist das so ein Problem: Hier verwende ich für den übergebenen Parameter ein _ als Postfix, oder nenne den Parameter anders (meist abgekürzt aber trotzdem noch erkennbar).

Warum? Wo gibt es da ein Problem?

zu ungarisch: siehe FAQ von Rund Um.
In OO Sprachen verwendet man ungarisch nicht - eine Kennzeichnung der Membervariablen ist OK.

Wobei ich eher hinten etwas dran hängen würde (wenn diese Kennzeichnung schon sein muss), als vorne. Weil dann kann die IDE helfen.

Man tippt
"fo" und die IDE schlägt vor: "foo_"
umgekehrt geht es nicht so gut:
Da man "m_f" schrieben muss
aber das ist im Prinzip egal.

Shade Of Mine

SirLant schrieb:

Ich denke, wenn man wirklich die Variablen so lokal wie möglich hält, was ja
keinerlei Nachteile bringt, eher im Gegenteil (spart Speicher, ist schneller
und man macht weniger Fehler), dann ist kurz nachzuschauen auch nicht zu viel
verlangt.

Mal abgesehen davon, dass meine IDE mir sowieso die Typen verrät - zB dadurch dass der Class Browser offen ist - und ich nur einen blick nach links werfen muss um die Typen zu erkennen (falls ich sie denn je brauchen sollte - was _sehr_ selten vorkommt).

SirLant

Shade Of Mine schrieb:

Wobei ich eher hinten etwas dran hängen würde (wenn diese Kennzeichnung schon sein muss), als vorne. Weil dann kann die IDE helfen.

Man tippt
"fo" und die IDE schlägt vor: "foo_"
umgekehrt geht es nicht so gut:
Da man "m_f" schrieben muss
aber das ist im Prinzip egal.

Aus diesem Grund verwende ich am liebsten nur _ , weil ich lieber ein prefix als ein
suffix habe und es schnell getippt ist

Jover

Shade Of Mine schrieb:

Jover schrieb:

Bei Konstruktoren ist das so ein Problem: Hier verwende ich für den übergebenen Parameter ein _ als Postfix, oder nenne den Parameter anders (meist abgekürzt aber trotzdem noch erkennbar).

Warum? Wo gibt es da ein Problem?

Naja ich dachte, dass im Konstruktor this nicht verwendet werden kann.

Foo::Foo(float value)
{
    this->value = value;
}

geht das?
bzw, geht das?

Foo::Foo(float value)
: value(value) {}

Shade Of Mine

Jover schrieb:

Naja ich dachte, dass im Konstruktor this nicht verwendet werden kann.
Foo::Foo(float value)
{
    this->value = value;
}
geht das?

Klar geht das.

Was du uU meinst ist, dass man this nicht in der Initialisierungsliste verwenden sollte.

bzw, geht das?

Foo::Foo(float value)
: value(value) {}

Klar geht das.
einzig ein bisschen doof ist folgendes:

Foo::Foo(float val)
: value(value) {}

@Mis2com:
nein welch große Erkenntnis und Idee. Lamesfaktor: 10

Welche Idiot benutzt denn Bitte this-> im Constructor??? Das wird wenn schon im Funktionsheader reingeschrieben des Konstruktors:

Foo::Foo (void) : m_value (0.0f) { }

bzw.:

Foo::Foo (float value) : m_value (value) { }

Die drei Einzigsten nützlichen Präfixe aus der Ungarischen Notation sind: C (bzw. I) sowie m_ für Member variablen (denn this->value finde ich persönlich Scheisse!) sowie g_. Den Rest aus dieser Notation kannste knicken.

Shade Of Mine

nix da schrieb:

Welche Idiot benutzt denn Bitte this-> im Constructor??? Das wird wenn schon im Funktionsheader reingeschrieben des Konstruktors:

Geil, du hattest noch nie Code in einem Ctor?

Jover

@Shade: Danke, für die Korrektur. Man lernt eben nie aus.

Mis2com

@nix_da:
Schön, dass du den Rest des Threads gelesen hast, sodass du dich in keinem Punkt wiederholt hast.

OK, _ als Suffix bzw. m_ als Präfix ist ok, C bei Klassen ist ja anscheinend auch unsinnig, außer bei Einheit in z.B. MFC, was sagt ihr zu I bei Schnittstellen?

Noch Fragen:

Tja, äh, aber dann wären Zeiger-Präfixe doch auch Quatsch, weil man das mit dem Zeiger auch schnell nachlesen kann?
Ich sehe darin allerdings insofern Sinn, als dass es nicht ein Hund ist, sondern nur ein Zeiger auf den Hund...
Frage ist jetzt natürlich, ob durch das * dieses Zeiger auf direkt mit zum Namen gehört, hm.
Ist es eigentlich schlechter Stil Monsterfunktionen zu machen, statt vielen vereinzelten, wenn man jeden Teil der Funktion ohnehin nur einmal benötigt, einzelne Abschnitte kommentiert und Variablen auch erst dann definiert, wenn sie nötig sind?
In meinem aktuellen Projekt habe ich so eine Funktion, es handelt sich direkt um main, also ich sehe da kein sonderlich großes Problem drin, aber es ist ja allgemein nicht besonders schön, oder?

Danke jedenfalls, die ungarische Notation werde ich in Zukunft wohl kaum noch verwenden.

Nochwas, Prädikate werden ja auch nicht mit prd präfixiert, wie kann man ein Prädikat denn dann bennenen, damit es klar wird?
Also paar Beispielbezeichnungen wäre nett.

Danke für die Hilfen bisher,

MfG Eisflamme

Shade Of Mine

Mis2com schrieb:

was sagt ihr zu I bei Schnittstellen?

Wozu?

Tja, äh, aber dann wären Zeiger-Präfixe doch auch Quatsch, weil man das mit dem Zeiger auch schnell nachlesen kann?
Ich sehe darin allerdings insofern Sinn, als dass es nicht ein Hund ist, sondern nur ein Zeiger auf den Hund...
Frage ist jetzt natürlich, ob durch das * dieses Zeiger auf direkt mit zum Namen gehört, hm.

Ist es nicht egal ob du einen Hund, oder einen Zeiger auf einen Hund hast?

Ist es eigentlich schlechter Stil Monsterfunktionen zu machen, statt vielen vereinzelten, wenn man jeden Teil der Funktion ohnehin nur einmal benötigt, einzelne Abschnitte kommentiert und Variablen auch erst dann definiert, wenn sie nötig sind?

Ja

In meinem aktuellen Projekt habe ich so eine Funktion, es handelt sich direkt um main, also ich sehe da kein sonderlich großes Problem drin, aber es ist ja allgemein nicht besonders schön, oder?

Mein main sieht in etwa so aus:

int main()
{
  try
  {
     Application app;
     app.run();
  }
  catch(...) //bzw. andere exceptions
  {
     cout<<"unbekannter Fehler\n";
  }
}

Was hast du da viel mehr drinnen stehen?
selbst app.run() ist nicht sonderlich lang...

Naja, manchmal habe ich auch längere Funktionen - nämlich dann wenn man eine hässliche C API ewig lang initialisieren muss - aber sowas kommt selten vor.

Nochwas, Prädikate werden ja auch nicht mit prd präfixiert, wie kann man ein Prädikat denn dann bennenen, damit es klar wird?
Also paar Beispielbezeichnungen wäre nett.

Wozu willst du das? Wir wollen doch keine präfixe und ähnliches. Also nur einen passenden Namen oder Schnickschnack.

zB
IpCompare um IP Adresse zu vergleichen

Mis2com

Hi,

ok.
Ich habe jetzt keine Klasse Main in diesem Sinne gehabt, wusste nicht, dass man das so tun soll, auch wenn es natürlich logisch ist, werde das ändern.
Dann bieten sich auch mehrere Funktionen eher an, weil ich mit mehreren globalen Funktionen meinem Geschmack nach zu sehr C programmiert hätte.
main so vollzustopfen ist aber ebenfalls eher C, das war mir nur nicht ganz bewusst, danke.

I für Interface-Präfix, z.B.:

IServer

Finde ich praktisch, weil man es so von einem StandardServer unterscheiden kann, weil ein StandardServer auch gerne den Namen Server hat.
...Compare also... ok, das leuchtet mir natürlich ebenfalls ein.

Gute Nacht, danke nochmal