in the style sheet you (frank? paul?) stated that "hungarian notation violates OO" or something to that effect. The place i work are talking about having standards (can you beleive they don't have them and they do alot of coding) and are leaning towards hungarian notation. I am against h.n. and need more ammo so please expound. thanks
I'll have a go. When Hungarian Notation (HN) was invented, the set of data types available in any given language was largely fixed. If a language provided (for example) short and long integers, character strings and single characters, pointera and arrays, then chosing and using HN prefixes was pretty straightforward. i for int, l for long, s for string and so on. Even adding modifiers like pl for a pointer to a long, as for an array of strings or sz for a zero-terminated string still remains understandable. However, even relatively primitive languages, such as C, have ways to extend the type mechanism through the likes of typedef and structure definitions. Allowing user types into a system can bend or even completely break HN. Using the whole new type name as a prefix can lead to very cumbersome variable and function names, and trying to abstract an abbreviation defeats the point of being able to determine the type immediately - you still have to look up the abbreviation in some sort of index. Imagine just adding a few typedefs, enums and structures to a HN program:
Try and work out what HN prefixes you would use for these types. Now if I want to define some aggregate variables, like an array of islands for a chain or archipelago, I would have to declare something like: struct island details aisland_detailsGalapagos; or struct island_details aidGalapagos. Neither of which seems a particularly good solution. With a fully flexible OO language, such as Smalltalk, Java, or even C++, almost every type in the system is a class type rather than a primitive type. And typical OO systems have a lot of classes. In a HN approach to a system like this, the type information prepended to variable names very rapidly becomes both cumbersome and difficult to understand. And that's even without the use of polymorphism. Polymorphism allows (typicaly through subclassing) containers, arrays and variables to hold contents of different types at different points in the program. The commonly used Java "Vector" for example can hold objects of any class. This is completely at odds with HN, which would require the type of the contents to be specified in the name of the vector variable. This final point is the real killer for most technically oriented people. In order to use HN, you really have to either not use polymorhism, or allow the match between name and type to sometimees slip - which defeats the point of HN. Likewise, in order to make good use of the immense power and flexibility of polymorphism, you really have to dispense with HN. Most serious OO naming styles emphasise naming of variable by meaning rather than by type. This allows classes to be changes, renamed, subclassed, split, joined etc. without having to rename variables and methods all over the system. This is an important form of encapsulation which allows effective maintenance of OO software without incurring great costs. Anyone involved in the deveopment of large systems knows that the smaller you can make the impact of a change, the smaller the chance of introducing bugs, so less of the system needs expensive regression testing before release. This is the killer for business oriented people. Choosing a naming style in an OO system which emphasises meaning over type can reduce software development costs and lead to fewer bugs. Does that help?
"in the style sheet you (frank? paul?) I thought that it is extracted from the Bible. I would like to know the absolute truth: who are the authors? "hungarian notation violates OO" May I ... ? Thanks anyway. I have read, or I make up, as usual, that setters and getters violate OO Reasoning: 1)"get"/"set" paradigm is MS's contribution to OOP. It is considered rude to get/set something directly. If you need something to be done, then give that job to that object without any extortion for your own job. 2) Objects are to communicate only through publicly determined/exposed interfaces.