Ungarische Notation und das restliche Gesocks!
-
Also, ich hab hier ein paar Kollegen, die mir die ganze Zeit einreden wollen, das ungarische Notation einfach unerlässlich ist. Selbstverständlich benutze ich diese nicht, da ich der Meinung bin, das ich mit Java eine Sprache habe, wo es nicht nötig ist. (in C++ erst Recht nicht!) Die Kollegen kommen übrigens aus der Delphie und VisualBasic-Welt. Und nur weil zu IT-Steinzeit-Zeiten mal MS (ist heilig) ungarische Notation benutzt hat, sollte man das auch die nächsten 100 Jahre fortführen.
Meine Frage: kennt jemand ein Buch, wo schwarz auf weiß drauf steht, das man den Mist heute nicht mehr braucht? Ich versuche wirklich Argumente und Beispiele zu bringen, aber die Kollegen können nicht rein denken... sonst würden sie es ja einsehen.
Also, wer kennt ein Buch, das am besten von einem Guru (Java oder C++) geschrieben wurde? Oder vielleicht eine offizielle Homepage eines Gurus, wo es drauf steht?
-
binden sind die Notationen sicher nicht aber nützlich
vorallem wenn sich ein anderer deinen quelltext anschauen muss weiss er eben immer genau welchen Datentyp du gerade verwendest.Deshalb muss ich eher deinen Kollegen zustimmen.
-
Taelan schrieb:
binden sind die Notationen sicher nicht aber nützlich
vorallem wenn sich ein anderer deinen quelltext anschauen muss weiss er eben immer genau welchen Datentyp du gerade verwendest.Und das bringt was?
-
Ungarische Notation, weg damit! Wer sauber programmiert und dabei sprechende Variablennamen verwendet, dessen Code kann man imo gut lesen.
Und Ungarische Notation in Java
Das hab ich ja noch gar nicht gehört...Übrigens kann ich pers. Quelltexte _ohne_ Notationen wesentlich besser lesen.
-
Taelan! Ich wollte nicht hören, warum ich UN einsetzen sollte und auch nicht darüber diskuttieren. Ich will eine Antwort auf meine Frage!
-
Wie man an den Postings von Artchi und GPC sieht, gibt es dafür keine sachlichen Argumente, sondern nur Meinungen.
Ich werde das Thema aber dem Autor von dem Buch 'DirectX vs. OpenGl in 21 Jahren' vorschlagen. Damit ihr auf euren Kreuzzügen was in der Hand habt.
Herzlichst,
ein leidenschaftlicher sys_UngNotNutzer.
-
-
So ad hoc wüsste ich jetzt kein Buch wo diesbezüglich was drinstehen würde (vielleicht "C++ Coding Standards" von Sutter & Alexandrescu?)... Aber ähnlich wie wenn du google bezüglich UN befragen würdest tippe ich dass deine Kollegen auch ein Buch auftreiben könnten wo UN als "Best Practice" gepriesen wird.
Artchi schrieb:
Meine Frage: kennt jemand ein Buch, wo schwarz auf weiß drauf steht, das man den Mist heute nicht mehr braucht? Ich versuche wirklich Argumente und Beispiele zu bringen, aber die Kollegen können nicht rein denken... sonst würden sie es ja einsehen.
hehe... "sonst würden sie es ja einsehen"
Was meinst du wie deine Kollegen deine Haltung einschätzen? 
Welche Argumente/Beispiele hast du denn benutzt?
Taelan schrieb:
binden sind die Notationen sicher nicht aber nützlich
vorallem wenn sich ein anderer deinen quelltext anschauen muss weiss er eben immer genau welchen Datentyp du gerade verwendest.Ah, ja.
Wie war nochmal das universelle Prefix für "MenuCommand"? Für "MediaCodec"? "MemoryCache"? "MultiCaster"? (ad infinitum...)
Ein 'o' vielleicht? Oder doch eher 'mc'? 'OMG'?Selbst wenn wir bei simpleren Fällen bleiben die das eigentlich interessante, den Variablennamen, nicht unkenntlich machen, was genau hast du davon?
Vielleicht ist der konkrete Datentyp lediglich ein "Implementationsdetail" eines Modells? Und wenn der Wert Beschränkungen unterliegt die dem Typ nicht inhärent dann ist UN eher noch hinderlich.
Wenn du anhand des Kontextes, Namens und der Verwendung nicht erkennen kannst was passiert & passieren soll wird es ohnehin Zeit sich genauer mit dem Code inklusive Deklaration auseinanderzusetzen.Das einzige was gelegentlich, uU, Sinn machen könnte ist "Systems Hungarian", aber das fällt dann wohl auch eher in den generellen Bereich sinnvolle Bezeichner...
-
SeppSchrot schrieb:
Wie man an den Postings von Artchi und GPC sieht, gibt es dafür keine sachlichen Argumente, sondern nur Meinungen.
Klar, entweder man mag's halt, oder man mag's nicht.
SeppSchrot schrieb:
Herzlichst,
ein leidenschaftlicher sys_UngNotNutzer.Waaah, hinfort mit dir...
finix schrieb:
Ah, ja.
Wie war nochmal das universelle Prefix für "MenuCommand"? Für "MediaCodec"? "MemoryCache"? "MultiCaster"? (ad infinitum...)
Ein 'o' vielleicht? Oder doch eher 'mc'? 'OMG'?
(Genauso ging's mir auch als ich mal Quellcode mit UN lesen und überarbeiten musste 
)
-
Artchi schrieb:
Meine Frage: kennt jemand ein Buch, wo schwarz auf weiß drauf steht, das man den Mist heute nicht mehr braucht? Ich versuche wirklich Argumente und Beispiele zu bringen, aber die Kollegen können nicht rein denken... sonst würden sie es ja einsehen.
Also, wer kennt ein Buch, das am besten von einem Guru (Java oder C++) geschrieben wurde? Oder vielleicht eine offizielle Homepage eines Gurus, wo es drauf steht?
Sutter & Alexandrescu: "Hungarian notation - Notations that incorporate type information in variable names have mixed utility in type-unsafe languages (notably C), are possiblebut have no benefits (only drawbacks) in object-oriented languages, and are impossible in generic programming."
Sutter & Hyslop: http://www.cuj.com/documents/s=7989/cujcexp1911hyslop/
Tim Ottinger: "HN was pretty important back when everything was an integer handle or a long pointer, but in C++ we have (and should have) a much richer type system. We don't need HN any more. Besides, encoded names are seldom pronounceable"
Micheal Feathers: "When Hungarian Notation
is used in OO languages it can be a band-aid for poor design. In good
programs if you want to know the type of a variable, it's often as simple as
looking up a couple of lines to where it is declared (as a parameter or a
local). The other place that it can be is where the instance variables are
declared. Very easy to find. When you have short methods, Hungarian is
totally superfluous. If you don't, well there is a bigger problem (long
methods) and using Hungarian doesn't solve it."Robert C. Martin: "it's duplication -- especially in C++, Java, C#, or any other statically typed language. HN is a *second* declaration of type.
Duplication is evil[...] The fact that it is easy to change a variable does not mean that it will be changed. HN is like comments. Comments are lies. So is HN. Or rather, that's the only safe way to view them. The older the
comment (or HN variable name) the more likely it is to be a lie."siehe auch: http://www.ootips.org/hungarian-notation.html
The Pragmatic Programmer: "Hungarian Notation [...] is utterly inappropriate on object-oriented systems."
Steve McConnel im Buch Code Complete über die Nachteile der klassischen HN:
"The result is a convention of little value, one that forces programmers to worry ambout manual type checking instead of letting the compiler check the types more rapidly and accurately.A second problem with that form of Hungarian is that it combines data meaning with data representation. When you declare a variable to be an integer, you shoudn't have to change the variable's name if you change it to a long integer.
[...]it encourages lazy, uninformative variable names. Programmers who name a handle to a window hwnd often neglect to describe the kind of window they're referring to.[...]Trading the semantics of the variable for a precise description of its type is a poor trade-off."
Viele weitere Meinungen: Why is Hungarian Notation Considered Evil?
-
Vielen Dank HumeSikkins und Sarfuan!
Habe noch das hier gefunden:
- Do not use Hungarian notation for field names. Good names describe semantics, not type.
- Do not apply a prefix to field names or static field names. Specifically, do not apply a prefix to a field name to distinguish between static and nonstatic fields. For example, applying a g_ or s_ prefix is incorrect.Quelle: MSDN
Habe mal alles zusammen getragen und in einer Mail an mein Kollegen verschickt.
Ich meine nur, wer gerne diese Notation ensetzen will kann das gerne machen. Aber er soll mich damit nicht belästigen.
-
habt ihr mal den link von sarfuan gelesen?
das beschreibt die UN etwas anders.
da werden in den prefixen Informationen gespeichert welche nicht aus den Typen selbst hervorgehen.
zB werden da Herkunften codiert um den Überblich im source zu halten ob strings aus vertrauenswürdigen Quellen stammen.
zB ist dort sName nicht String name sondern safeName im Gegenteil zu usName als unsafe.
-
@b7f7
Das ist aber ebenfalls nicht sehr ideal, da die Konvention vom Compiler nicht überprüft wird. Bei einem sName=usName oder einem system(usName); sagt der Compiler nichts. In Objekt Orientierten Sprachen hat man den Vorteil, dass man dafür einfach eigene Typen definiert, die entsprechendes Verhalten erzwingen. Oder so ein tainted-System, wie in Ruby.
-
UN ist nicht für den compiler gedacht sondern als codeguide für einen Programmierer.
-
b7f7 schrieb:
habt ihr mal den link von sarfuan gelesen?
das beschreibt die UN etwas anders.
da werden in den prefixen Informationen gespeichert welche nicht aus den Typen selbst hervorgehen.
zB werden da Herkunften codiert um den Überblich im source zu halten ob strings aus vertrauenswürdigen Quellen stammen.
zB ist dort sName nicht String name sondern safeName im Gegenteil zu usName als unsafe.Naja.. wenn man den Aufwand schon betreibt (das muss ja auch irgendwo konsistent & aktuell & unübersehbar dokumentiert sein), wieso nicht gleich richtig?
Joel on Software, ent-ungarisiert:
class EncodedString : boost::totally_ordered<EncodedString, std::string> , boost::addable<EncodedString> { friend EncodedString encode( std::string const& s ); public: std::string toString() const { return str; } EncodedString& operator+=( EncodedString const& es ) { str += es.str; return *this; } bool operator<( EncodedString const& rhs ) const { return str < rhs.str; } bool operator<( std::string const& rhs) const { return str < rhs; } bool operator==( EncodedString const& rhs ) const { return str == rhs.str; } bool operator==( std::string const& rhs ) const { return str == rhs; } private: EncodedString( std::string const& s ) : str(s) { } std::string str; }; // class EncodedString EncodedString encode( std::string const& s ) { // ... } void write( EncodedString const& es ) { // ... }Jemand der sich mit C++ auskennt nimmt sich etwas mehr als 4-5min Zeit, bastelt so'nen Typ richtig, und alles ist gut, auch ohne UN.
-
Taelan schrieb:
vorallem wenn sich ein anderer deinen quelltext anschauen muss weiss er eben immer genau welchen Datentyp du gerade verwendest.
Dieses Argument ist mindestens so alt wie UN selbst.
Und da wir jetzt moderne IDEs haben, sogar im Freeware Bereich, wirkt das mittlerweile echt lächerlich.
Zudem sollte man in der heutigen Zeit, wo generische Programmierung immer wichtiger wird, mehr kontextbasiert als typbasiert denken. Das sollten wir besser den Low-Level Leuten überlassen und uns in OO Sprachen auf andere Sachen konzentrieren.btw:
Wenn ich Sachen wie lpzsFormat sehe, wird mir richtig übel.
-
Vor allem wenn man bei der Auto-Completion erstmal diesen Buchstabensalat tippen muss um zum eigentlichen Wort zu kommen
-
Weshalb ich bei C-Code immer gerne einen Postfix statt des Präfix verwende (o;