Nochmal: Ungarische Notation
-
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.)
-
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
-
SirLant schrieb:
Würde normale gerne ein C vor den Klassennamen weglassen, aber damit es einheitlich ist schreibe ich ein C davor [...]
Womit einheitlich?
-
Steht doch im Satz darüber, mit der MFC, da diese immer ein C davor schreibt.
-
Dazu gabs mal einen schönen Link. Leider kann ich ihn nicht mehr finden, aber vielleicht kennt jemand die Seite, auf der etwa folgendes steht:
Die Compilerhersteller bieten Klassenbibliotheken an, wie z.B. MS mit seiner MFC. Wenn die nun aber eine Klasse Window anbieten, besteht eine recht hohe Kollisionsgefahr (in normalem Code ist eine eigene Window-Klasse gar nicht mal so unwahrscheinlich).
Deswegen haben die von MS sich gedacht: Verwenden wir ein Präfix! Denn damit kann es nicht mehr zu Kollisionen kommen. (Namespaces gabs damals noch nicht).
Dummerweise ging dieser Schuss ziemlich nach hinten los, weil viele Programmierer gedacht haben: "Microsoft setzt ein C vor die Klassennamen. Für irgendwas wird das wohl gut sein, denn sonst hätten die das nicht gemacht. Also machen wir das auch."
Damit ist das eigentliche Ziel, nämlich die Vermeidung von Kollisionen, total untergegangen.Konsequenterweise dürftest du das C also nur benutzen, wenn du die MFC programmierst. Denn normale Klassen (non-MFC) haben kein Prefix.
Mit (non-MFC) meine ich alle Klassen, die ein normaler Programmierer selbst schreibt, folglich nicht aus der MFC stammen.
-
Cool, wenn ich Dienste der MFC nutze, dann muss natürlich mein ganzes Programm im MFC-Stil geschrieben sein.
Oh shit, aber manchmal benutz ich auch noch die STL.
Deswegen haben die von MS sich gedacht: Verwenden wir ein Präfix! Denn damit kann es nicht mehr zu Kollisionen kommen. (Namespaces gabs damals noch nicht).
Naja die MFC ist doch für C++ geschrieben. Oder gabs da die namespaces auch nicht von Anfang an?
-
Ne gab es nicht Optimizer.
Ich benutze in MFC Programmen das C, ganz einfach weil die Klassen großteils, naja
eigentlich alle, bis auf sehr wenige die ich selber schreiben, von Klassen aus der
MFC abgeleitet sind und somit zu einem Teil der MFC werden.
Sonstige Klassen haben kein C im Namen, da sie unabhängig sind, es sei denn sie
verwenden natürlich intern die MFC.
-
Dass eine Klasse MFC-Elemente enthält, sollte wirklich kein Grund sein diese Klasse als "Teil der MFC" anzusehen und ihr ein C zu verpassen.
Auch von der MFC abgeleitete Klassen dürften konsequenterweise kein C erhalten, denn sie sind definitiv nicht "Teil der MFC".
Zur MFC gehören nur die Klassen, die in der MSDN unter "MFC" dokumentiert sind.
Ein normaler Programmierer kann von diesen Klassen zwar ableiten oder sie einbinden, die MFC dadurch aber nicht erweitern.
Genausowenig kann man eigene STL-Klassen schreiben. Die STL-Implementation STLPort enthält z.B. die Klasse hash_set. Diese Klasse ist dennoch nicht "Teil der STL".
-
@cd9000, doch es ist ein Grund, denn man soll in einem Projekt Konsistenz in der
Namensgebung halten und wenn ich ein MFC Projekt erstelle, erstellt mir der
Assistent automatisch Klassen mit dem C im Namen, wenn ich eine neue Klasse
hinzufügen möchte und gebe als ersten Buchstaben C ein, so werden die Felder mit
den Dateinamen nicht ausgefüllt, erst mit den anderen Buchstaben (CFoo, wird dann Foo.h und Foo.cpp).Die MFC zwingt mich also dazu um Konsistenz zu wahren.
-
Nicht die MFC, sondern die IDE.
Deshalb erstelle ich meine Klassen mittels "Datei neu" und schreibe dann "von Hand".@Optimizer
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.An sich vom Entwicklungsstandpunkt und der nötigen Abstraktion richtig. Es spricht ja aber nichts dagegen beides zu tun -> Name bezeichnet die Art des Hundes und Prä- bzw. Suffix den technischen Kontext.
Ich sehe es hier wirklich aus der Sicht von jemandem, der relativ häufig in kurzer Zeit Fremdtools nutzen und verstehen muß und da selbst kurzes Nachsauen als lästig empfindet.
-
TheBigW schrieb:
Nicht die MFC, sondern die IDE.
Deshalb erstelle ich meine Klassen mittels "Datei neu" und schreibe dann "von Hand".Makro schreiben, dass die Arbeit übernimmt
Gibt da genug freies.An sich vom Entwicklungsstandpunkt und der nötigen Abstraktion richtig. Es spricht ja aber nichts dagegen beides zu tun -> Name bezeichnet die Art des Hundes und Prä- bzw. Suffix den technischen Kontext.
Lies mal die FAQ von Run um - dann wirst du auch Humes Beispiel sehen und erkennen warum zuviel Information böse ist.
Ich sehe es hier wirklich aus der Sicht von jemandem, der relativ häufig in kurzer Zeit Fremdtools nutzen und verstehen muß und da selbst kurzes Nachsauen als lästig empfindet.
Und da ist es wichtig ob du einen float oder double vor dir hast?
Ich habe dann immer Probleme rauszufinden wie die Funktion jetzt heisst und ob sie das richtige macht.
Ich hatte noch nie Probleme mit dem Typen einer Variablen - zumal es bei mir sowieso fast nur Klassen gibt (und da hast du doch nicht wirklich auch prefixe, oder?)
-
SirLant schrieb:
[...] wenn ich ein MFC Projekt erstelle, erstellt mir der
Assistent automatisch Klassen mit dem C im Namen, wenn ich eine neue Klasse
hinzufügen möchte und gebe als ersten Buchstaben C ein, so werden die Felder mit
den Dateinamen nicht ausgefüllt, erst mit den anderen Buchstaben (CFoo, wird dann Foo.h und Foo.cpp).Du kannst doch trotzdem Klassen ohne C-Präfix erstellen?
Wenn der Klassenname zufällig mit einem C beginnt und die IDE meint da ruminterpretieren zu müssen, setzt du die Dateinamen eben manuell. In dem genannten Dialog gibt es eine Schaltfläche dafür.
-
Programmiert doch mal in einer nicht zur Compilezeit Typisierten Sprache.
|foo| foo := 5. foo := Apfelbaum new. foo := 'Hallo' reverse.Sicherlich kein sinnvolles Beispiel und sowas würde auch keiner machen, aber es lenkt das Denken in die richtige Richtung.
-
@Shade:
Lies mal die FAQ von Run um - dann wirst du auch Humes Beispiel sehen und erkennen warum zuviel Information böse ist.
Hab ich getan. Was ich in dem Fall meinte ist auch eher eine Unterscheidung bei Instanzen und Pointern auf Instanzen durch Präfix p. Klassen würde ich auch nie "Ver_ungarisieren", es sei denn sie sind irgendwo Member ( ob nun durch m_ , oder nur _ ist wohl eher Geschmackssache ).
Interfaces bekommen bei mir idr. auch ein I, aber für mich ist auch nicht jede abstrakte Klasse ein Interface, sondern nur, wenn ich sie ausschließlich zum Bereitstellen einer Schnittstelle verwende (keine weitere Funktionalität).
Ob float oder double spielt da sicher keine Rolle, aber irgendwie finde ich es immer ganz schön einer Variablen anzusehen, das sie z.B. ein String ist ( z.B.: strValue ). Dabei ist für mich aber alles String ( std::string, char[], CString.... ).
Keine Frage, ich muß das erstmal verdauen. Vielleicht lasse ich mich auch noch "Entungarisieren".
-
TheBigW schrieb:
ein String ist ( z.B.: strValue ). Dabei ist für mich aber alles String ( std::string, char[], CString.... ).
Und inwiefern hast du da besondere Informationen über den Typ? Wenn du ihn verwenden willst, musst du sowieso nachschauen was es jetzt für ein Typ ist...
-
Damit hast du mich Schachmatt. Noch ein letzter bescheidener Versuch eines Gegenargumentes:
Folgendes habe ich vor kurzem in einem Tool gefunden:
_name = name;
_attributes = attributes;
_parent = parent;wenn ich jetzt Versuche ein fremdes Klassengerüst zu verstehen, so hilft es mir immer für das grobe Verständis irrelevantes auszuschließen. In diesem Fall wäre dann:
_strName = strName;
_strAttributes = strAttributes;
_parent = parent;schöner gewesen, da ich Name und Attributes aus der Betrachtung ausschließen kann. Sozusagen nicht, um zu wissen, das strXX ein String ist, sondern um zu sehen, das parent eine Instanz einer zum Klassengerüst gehörigen Klasse ist.
Aber solange man eine IDE mit der schönen Option "Gehe zu Definition von ..." hat.....
-
Das "Gehe zu Definition von ..." ist ziemlich Zeitraubend, find ich, es ist viel
angenehmer, wenn man einfach mit dem Cursor über die Variable fährt und dann ein
Tooltip (heißen ja so oder?) erscheint mit der Deklaration
-
Die heutigen IDEs sind so gut, dass man sich keine Gedanken mehr um eine Notation machen muss. Ich gebe einen Variablennamen gefolgt von einem Punkt ein und die IDE wandelt um in '->', weil der eingegebene Variablenname zu einem Pointer gehört. Anschließend geht eine Liste mit allen Members auf. Einfacher geht es wohl kaum.
-
MaSTaH schrieb:
Ich gebe einen Variablennamen gefolgt von einem Punkt ein
Ne. Du gibst nur die ersten 2-3 Buchstaben des Variablennamens ein und drückst dann Enter
Noch ein Nachteil der ungarischen Notation:
strVal - da muss ich 4 Buchstaben schreiben, damit die IDE mir einen vernünftigen Vorschlag geben kann, da ich ja vermutlich mehrere Strings habe.
-
Ja, toll, also entwickelt ihr für Leute, die neue, teure IDEs haben?
Was bezeichnet ihr überhaupt als tolle, neue IDE? Und wieviel kostet sowas?