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.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,af40e09e753872c X-Google-Attributes: gidfac41,public X-Google-Thread: 1014db,30e368bdb3310fe5 X-Google-Attributes: gid1014db,public X-Google-Thread: 109fba,f292779560fb8442 X-Google-Attributes: gid109fba,public X-Google-Thread: 10db24,30e368bdb3310fe5 X-Google-Attributes: gid10db24,public X-Google-Thread: 103376,30e368bdb3310fe5 X-Google-Attributes: gid103376,public X-Google-Thread: f8c65,30e368bdb3310fe5 X-Google-Attributes: gidf8c65,public X-Google-Thread: 1008e3,30e368bdb3310fe5 X-Google-Attributes: gid1008e3,public From: seebs@solutions.solon.com (Peter Seebach) Subject: Re: Hungarian notation Date: 1996/05/21 Message-ID: <4nsg3f$liu@solutions.solon.com>#1/1 X-Deja-AN: 155923573 references: <4adem2$b5s@mercury.IntNet.net> <4n6off$6e2@mikasa.iol.it> <3198F30F.2A2@zurich.ibm.com> organization: Usenet Fact Police (Undercover) reply-to: seebs@solon.com newsgroups: comp.lang.ada,comp.lang.c++,comp.lang.c,comp.lang.modula3,comp.lang.modula2,comp.edu,comp.lang.eiffel Date: 1996-05-21T00:00:00+00:00 List-Id: In article , mAg wrote: (This is not kosher; never use _'s at the beginnings of names, unless you feel like memorizing all of the implementation namespace.) >typedef struct __ZZ__ >{ >int iSomething; >char *achSomething; >} ZZ; >ZZ *pZz; >int *pInt; >char *pChar; >Which one of these examples violate encapsulation???? The problem is that now, you'll see code like pZz->iSomething = 3; which is telling you that it's an int. That breaks encapsulation; you only need to know that it's vaguely arithmetic, and if it's changed to unsigned, you should neither know nor care. Fundementally, this sort of pseudo-Hungarian buys you nothing. The variable names turn into small, frequently innaccurate comments. They don't tell you what you need to know. If you would use interface, rather than implementation, to decide prefixes, it would make sense. Consider: Years later, you need to change this... You need to use a function... So ZZ has a member int (*pifFoov)(void); which is always set roughly correctly, and we go to #define iSomething (*(pifFoov)()) or something similar. (I know, this isn't precisely right.) Suddenly, the name is a blatant lie. How about this: Notate the following declaration correctly: FILE *Foo; ... Hmm. Maybe it's "pst". Nope, FILE may not be a struct. Maybe it's "pch". Nope, file may not be a char, even though FILE * is often really a pointer to char. Sometimes, it's a pointer to an int. Sometimes, it's really a pointer containing a converted int, and will never actually be used as a pointer. Any naming convention that tries to tell you the internals of an abstract is fundementally, and completely, broken. -s -- Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach. Unix/C Wizard - send mail for help, or send money for consulting! Unsolicited email is not welcome, and will be billed for at consulting rates. The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html