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=0.1 required=5.0 tests=BAYES_05,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,f292779560fb8442 X-Google-Attributes: gid109fba,public X-Google-Thread: fac41,af40e09e753872c X-Google-Attributes: gidfac41,public X-Google-Thread: f8c65,30e368bdb3310fe5 X-Google-Attributes: gidf8c65,public X-Google-Thread: 103376,30e368bdb3310fe5 X-Google-Attributes: gid103376,public X-Google-Thread: 1008e3,30e368bdb3310fe5 X-Google-Attributes: gid1008e3,public X-Google-Thread: 10db24,30e368bdb3310fe5 X-Google-Attributes: gid10db24,public X-Google-Thread: 1014db,30e368bdb3310fe5 X-Google-Attributes: gid1014db,public From: z007400b@bcfreenet.seflin.lib.fl.us (Ralph Silverman) Subject: Re: Hungarian notation Date: 1996/06/05 Message-ID: <4p494a$etm@nntp.seflin.lib.fl.us>#1/1 X-Deja-AN: 158607043 references: <4adem2$b5s@mercury.IntNet.net> <4ahka7$o9m@inrou.erno.de> <4n6off$6e2@mikasa.iol.it> <3198F30F.2A2@zurich.ibm.com> <31A4D2FC.1F8F@netvision.net.il> followup-to: comp.lang.ada,comp.lang.c++,comp.lang.c,comp.lang.modula3,comp.lang.modula2,comp.edu,comp.lang.eiffel organization: SEFLIN Free-Net - Broward newsgroups: comp.lang.ada,comp.lang.c++,comp.lang.c,comp.lang.modula3,comp.lang.modula2,comp.edu,comp.lang.eiffel Date: 1996-06-05T00:00:00+00:00 List-Id: 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