Subj : Re: How to name variables in a program?
To   : comp.programming
From : peetm
Date : Tue Jul 26 2005 03:39 pm

I'm not so sure that this is the case these days, i.e., historically, this 
was done so that one could tell something about the variable from its name - 
without going off and playing 'hunt the declaration'.  However, these days, 
any IDE worth using will let you easily move the a variable declarations 
(and back again) with little effort - so, as using prefixes etc ultimately 
do add some 'clutter' to the most important 'usage' part of the variable's 
name, I think you ought to consider *not* using them.

"Flavius Vespasianus" <nl@nl.com> wrote in message 
news:uBCEe.8266$oZ.3771@newsread2.news.atl.earthlink.net...
> "SerGioGio" <nospam> wrote in news:4297e636$1@news.starhub.net.sg:
>
>> Hello,
>>
>> Having a strong convention for naming your variables in your program
>> is an important issue often overlooked.
>> Can anyone point me to a good source on the web dealing with this
>> issue?
>
> A lot depends upon what language you are using.
>
> In assembly language, is it common to use some kind of prefix notation to
> indicate the type. A prefix system like this:
>
> MOVL RMS$L_ABC(R1), RMS$B_XYZ (R2)
>
> can point out obvious coding bugs.
>
> Unfortunately, due to the company most notorious for producing buggy
> software, such prefix notations have found their way into other
> programming languages. We've all seen the ridiculous "Hungarian" notation
> that some developers seem to slavishly copy in their C, and C++ code
> where it is both unnecessary and a bad coding practice. (Encapsulation is
> one of the tenants of OO programming. Naming schemes based upon type are
> contrary to that.)
>
> In Object Pascal, the unit name is in the same namespace as the
> declarations within. Therefore, it is common to use the prefix "T" before
> type names to distinguish the unit from the classes within. So there,
> some limited prefixes are necessary.
>
> In a typical C++ environment, you might find a coding standard based upon
> variations of
>
> firstsecond
> FirstSecond
> secondFirst
> FIRSTSECOND
> First_Second
> first_second
> first_Second
> FIRST_SECOND
>
> to indicate various programatic elements, such as class, constant, member
> function, member variable.
>
> However, it is worth nothing that all the standard library functions are
> all lowercase names. Thus, any names using uppercase will not conflict.

.