Nochmal: Ungarische Notation

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

Warum wollt ihr denn die Variablen immer so technisch benennen? Ist das wichtig, ob es ein Hund ist oder ein Zeiger auf einen Hund? Viel wichtiger ist doch, dass es der Hund ist, der die Passanten auf Drogen beschnuppert, der Wachhund, oder der Hund, der einfach nur faul rumliegt oder eine andere Aufgabe hat.
Beschreibt halt, was der Hund für ne Funktion und für einen Sinn in dem Programm hat und nicht, dass es ein globaler const-Zeiger auf ein Hund-Objekt ist. Das kann ich mit minimalen Aufwand nochmal nachschauen, wenn es mir entfallen ist.
(Das betrifft jetzt die Benennung von Instanzen.)

SirLant

Also ein p als prefix für Zeiger kann ich verstehen, so sieht man sofort wo man
den . und wo den -> benutzen muss, es sei denn man hat ne IDE die das automatisch
korrgiert

Also das mit dem p hab ich mir inzwischen auch angewohnt, bei mir sieht ne Variable
im schlimmsten Fall so aus: g_pHund
Globale Objekte benutze ich höchst selten (wenn Konstanten), wodurch es ein _pHund
ist und wenn die Variable öffentlich zugänglich ist (die MFC versaut einem den Stil ), dann nur
ein pHund, es sei denn es ist nen MFC Projekt dann m_pHund

Christoph

SirLant schrieb:

Würde normale gerne ein C vor den Klassennamen weglassen, aber damit es einheitlich ist schreibe ich ein C davor [...]

Womit einheitlich?

SirLant

Steht doch im Satz darüber, mit der MFC, da diese immer ein C davor schreibt.