From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 10db24,30e368bdb3310fe5 X-Google-Attributes: gid10db24,public X-Google-Thread: fac41,af40e09e753872c X-Google-Attributes: gidfac41,public X-Google-Thread: 109fba,f292779560fb8442 X-Google-Attributes: gid109fba,public X-Google-Thread: f8c65,30e368bdb3310fe5 X-Google-Attributes: gidf8c65,public X-Google-Thread: 103376,30e368bdb3310fe5 X-Google-Attributes: gid103376,public X-Google-Thread: 1014db,30e368bdb3310fe5 X-Google-Attributes: gid1014db,public X-Google-Thread: 1008e3,30e368bdb3310fe5 X-Google-Attributes: gid1008e3,public From: Dave Toland Subject: Re: Hungarian notation Date: 1996/05/24 Message-ID: <31A5B15E.321F@platsol.com>#1/1 X-Deja-AN: 156511855 references: <4adem2$b5s@mercury.IntNet.net> <4n6off$6e2@mikasa.iol.it> <3198F30F.2A2@zurich.ibm.com> <4nsg3f$liu@solutions.solon.com> <31a3b322.442404233@sqarc> <4o35bu$ut8@sol.caps.maine.edu> content-type: text/plain; charset=us-ascii organization: Platinum Solutions mime-version: 1.0 newsgroups: comp.lang.ada,comp.lang.c++,comp.lang.c,comp.lang.modula3,comp.lang.modula2,comp.edu,comp.lang.eiffel x-mailer: Mozilla 2.01 (Win95; I) Date: 1996-05-24T00:00:00+00:00 List-Id: slary61@maine.maine.edu wrote: | dewar@cs.nyu.edu (Robert Dewar) wrote: | > Hungarian notation is certainly a remarkable demonstration of how few people | > have learned and understood data abstraction. What's most interesting is | > how difficult it is for its advocates to see this point, but I suppose that | > is not surprising. If you never understood what abstraction is about, then | > of course adopting a notation that destroys it will not concern you. | | Perhaps Bill Gates will be contacting you for that explanation. | Although the examples you cite support your opinion, the bottom | line is that some of the largest software developers in the world | insist on code using Hungarian Notation. | | Why? Biggest or most doesn't necessarily mean correct. Hungarian notation has some advantages, but keep in mind it was developed for C, not C++. C is a procedural language, and programs written in it have long been plagued by problems with mismatches of fundamental data types. The addition of function prototypes to the language did much to ameliorate the problem for call interfaces, except for functions like printf for which compile time checking is not possible *in the general case* (yes, I know gcc can check printf calls, but only because the compiler has special knowledge of that runtime routine). And prototypes can only diagnose mismatches for invariant argument lists if they are consistently used. ANSI C only requires prototypes for variable argument list functions, and in fact a large body of code cannot use prototypes without tedious macro magic because it must compile on platforms for which ANSI compilers are not or were not available. This is where Hungarian notation can help compensate for the failures of the language. But C++ is an object oriented language. Despite its ancestry, its philosophy is completely different than that of C. One of the key principles is to hide the implementation details of the data and to deal instead with the data's abstract properties. The very *last* thing you want to do in that paradigm is name your variables in a way that emphasizes their underlying implementation. As for me, I've been practicing data abstraction in my C coding for over ten years, so I've held a certain distaste for Hungarian notation for all that time as well. I am very aware of the shortcomings of C in terms of type checking, but rather than constraining variable names, I have favored instead a liberal use of typedefs to form abstract data types. I still need to know the underlying types for some purposes, such as displaying with the printf family, but I try to encapsulate the code that knows the internal format as much as possible. I try to minimize the lifetime and scope of variables, and the longer the lifetime, the more careful I am in the naming of the variable. So "i" is an appropriate name for a variable used an an index for a 3-line iteration, and "CurrentSourceFileInfo" is an appropriate name for a global structure (if it really must be global) used for all operations on the source file presently open. Imposing arbitrary rules results in code every bit as opaque as without the rules. Teaching good judgement results in maintainable code. Informed peer review of code can point out poor name selection and treat it as the defect that it is. -- I protest! I am *NOT* a Merry Man! Dave Toland Platinum Solutions, Inc. det@platsol.com