Re: Hungarian notation

[z007400b@bcfreenet.seflin.lib.fl.us (Ralph Silverman)]

Oleg Kagan (ok@netvision.net.il) wrote:
: mAg wrote:
: > 
: > In article <3198F30F.2A2@zurich.ibm.com> (Tue, 14 May 1996 13:54:39 -0700),
: > wgk@zurich.ibm.com says :
: > >
: > 
: > >
: > >And is absolutely horrible! It serves little purpose especially in the world of
: > >C++ as we can invent our own data types and attempting to extend the convention
: > >to include our newly defined types makes the code unreadable.
: > 
: > This is comp.lang.c. and apart from that there is nothing horrible. It is, in fact, the
: > best thing that has happened to C language.
: > 
: > >
: > >In addition it makes it difficult to change a int to an unsigned int or to
: > >a long without updating every occurence of the variable name in the code.
: > 
: > Which means that the original design was not well thought of...
: > 
: > I write programs using hard-core hungarian and I love it. The hungarian-haters can still
: > read my programs by simply refusing to interpret the value by looking at the variable
: > name.
: > 
: > Someone raised a question about encapsulation, i.e hungarian killing encapsulation.
: > 
: > Why so?
: > 
: > here are few examples :
: > 
: > typedef struct __ZZ__
: > {
: > int iSomething;
: > char *achSomething;
: > } ZZ;
: > 
: > ZZ *pZz;
: > 
: > int *pInt;
: > char *pChar;
: > 
: > Which one of these examples violate encapsulation????
: > 
: > --
: > /* --------------------------------------------------------
: >                       MAG@ESKIMO.COM
: > http://www.eskimo.com/~mag/index.html
: > ***********************************************************
: > To understand recursion one must first understand recursion
: > ***********************************************************
: > -------------------------------------------------------- */
:  I You want Your code look like nice... so...
: to define array of char i use a little bit different notation

: char ac_ExampleOfArrayOfChar[]; // :)

--
**********begin r.s. response***********

	off the cuff response to issue
	of
		altering data types
	in material cited above,
		is unduly casual!

	alteration of data types in
	such,  does not necessarily result
	from vacillation or from
	lack of planning!

**********end r.s. response*************
Ralph Silverman
z007400b@bcfreenet.seflin.lib.fl.us