Connecting Tech Pros Worldwide Help | Site Map

Looking for good naming convention for class attributes

  #1  
Old July 22nd, 2005, 06:10 AM
Sandeep Sharma
Guest
 
Posts: n/a
For many years I have been following the convention of naming all
class attributes with a leading underscore. This enables me to
quickly identify the class attributes when I encounter them in the
source code. Even the GoF book follows this convention, although it's
true that the GoF book is not an authoritative source for coding
guidelines.

Recently a colleague remarked that using a leading underscore is a bad
programming practice that should be avoided at all costs. According
to her this has to do with the fact that the compiler naming mangling
procedure also sticks leading underscores and therefore using
underscores in the source code makes the job of following the
post-processed source code (should there ever be a need) very
difficult.

Any comments?

Regards,
Sandeep
  #2  
Old July 22nd, 2005, 06:11 AM
Jeff Schwab
Guest
 
Posts: n/a

re: Looking for good naming convention for class attributes


Sandeep Sharma wrote:[color=blue]
> For many years I have been following the convention of naming all
> class attributes with a leading underscore. This enables me to
> quickly identify the class attributes when I encounter them in the
> source code. Even the GoF book follows this convention, although it's
> true that the GoF book is not an authoritative source for coding
> guidelines.
>
> Recently a colleague remarked that using a leading underscore is a bad
> programming practice that should be avoided at all costs. According
> to her this has to do with the fact that the compiler naming mangling
> procedure also sticks leading underscores and therefore using
> underscores in the source code makes the job of following the
> post-processed source code (should there ever be a need) very
> difficult.
>
> Any comments?
>
> Regards,
> Sandeep[/color]

It's not just the (relatively obscure) issue you mention. You're not
allowed to use leading underscores; they're reserved for the
implementation, per section 17.4.3.1.2 of the standard. You see lots of
leading underscores in standard library code; using leading _ yourself
can interfere with the library, and certainly isn't portable.

  #3  
Old July 22nd, 2005, 06:11 AM
Derek
Guest
 
Posts: n/a

re: Looking for good naming convention for class attributes


"Jeff Schwab" wrote...[color=blue]
> For many years I have been following the convention of
> naming all class attributes with a leading underscore.
> This enables me to quickly identify the class attributes
> when I encounter them in the source code. Even the GoF
> book follows this convention, although it's true that
> the GoF book is not an authoritative source for coding
> guidelines.
>
> Recently a colleague remarked that using a leading
> underscore is a bad programming practice that should be
> avoided at all costs. According to her this has to do
> with the fact that the compiler naming mangling procedure
> also sticks leading underscores and therefore using
> underscores in the source code makes the job of following
> the post-processed source code (should there ever be a
> need) very difficult.
>
> Any comments?
>
> Regards, Sandeep[/color]

As Jeff already pointed out, the leading underscore is reserved by the
implementation. Using leading underscores is not only bad practice
but also not permitted by the standard. These days many books prefer
the *trailing* underscore:

struct X
{
int someDataMember_;
};

I don't like this convention and prefer an m_ prefix (despite it's
affiliation with Microsoft):

struct Y
{
int m_someDataMember;
};


  #4  
Old July 22nd, 2005, 06:11 AM
Rob Williscroft
Guest
 
Posts: n/a

re: Looking for good naming convention for class attributes


Derek wrote in news:bu128u$cds29$1@ID-46268.news.uni-berlin.de:
[color=blue]
>
> As Jeff already pointed out, the leading underscore is reserved by the
> implementation. Using leading underscores is not only bad practice
> but also not permitted by the standard. These days many books prefer
> the *trailing* underscore:
>
>[/color]

Using a leading underscore is leagal as long as:

A) it isn't followed by another underscore,
B) it isn't followed by an uppercase letter,
C) it doesn't declare an identifier in the global namespace.

Additionally identifiers with 2 consecutive underscores are
allways reserved (hence (A) above).

Rob.
--
http://www.victim-prime.dsl.pipex.com/
  #5  
Old July 22nd, 2005, 06:11 AM
Jeff Schwab
Guest
 
Posts: n/a

re: Looking for good naming convention for class attributes


Rob Williscroft wrote:[color=blue]
> Derek wrote in news:bu128u$cds29$1@ID-46268.news.uni-berlin.de:
>
>[color=green]
>>As Jeff already pointed out, the leading underscore is reserved by the
>>implementation. Using leading underscores is not only bad practice
>>but also not permitted by the standard. These days many books prefer
>>the *trailing* underscore:
>>
>>[/color]
>
>
> Using a leading underscore is leagal as long as:
>
> A) it isn't followed by another underscore,
> B) it isn't followed by an uppercase letter,
> C) it doesn't declare an identifier in the global namespace.
>
> Additionally identifiers with 2 consecutive underscores are
> allways reserved (hence (A) above).
>
> Rob.[/color]

Excuse me, you're quite right. Leading underscores inside namespaces
(outside std) should be OK, although I personally detest them. I am
also a fan of m_name for private member data, mostly because I haven't
thought of anything better.

  #6  
Old July 22nd, 2005, 06:11 AM
red floyd
Guest
 
Posts: n/a

re: Looking for good naming convention for class attributes


Jeff Schwab wrote:[color=blue]
> Rob Williscroft wrote:[/color]
[discussion of standard redacted][color=blue]
>
> I am
> also a fan of m_name for private member data, mostly because I haven't
> thought of anything better.
>[/color]

Yep. That's the only good Hungarianism I've found.

  #7  
Old July 22nd, 2005, 06:11 AM
Nick Hounsome
Guest
 
Posts: n/a

re: Looking for good naming convention for class attributes



"Rob Williscroft" <rtw@freenet.REMOVE.co.uk> wrote in message
news:Xns946FA3A46E101ukcoREMOVEfreenetrtw@195.129. 110.130...[color=blue]
> Derek wrote in news:bu128u$cds29$1@ID-46268.news.uni-berlin.de:
>[color=green]
> >
> > As Jeff already pointed out, the leading underscore is reserved by the
> > implementation. Using leading underscores is not only bad practice
> > but also not permitted by the standard. These days many books prefer
> > the *trailing* underscore:
> >
> >[/color]
>
> Using a leading underscore is leagal as long as:
>
> A) it isn't followed by another underscore,
> B) it isn't followed by an uppercase letter,
> C) it doesn't declare an identifier in the global namespace.
>[/color]

This true but why do you want to have to remember these cases?
It's simpler just to say never to leading underscores.
[color=blue]
> Additionally identifiers with 2 consecutive underscores are
> allways reserved (hence (A) above).
>
> Rob.
> --
> http://www.victim-prime.dsl.pipex.com/[/color]


  #8  
Old July 22nd, 2005, 06:12 AM
Daniel T.
Guest
 
Posts: n/a

re: Looking for good naming convention for class attributes


sandeep6699@yahoo.com (Sandeep Sharma) wrote:
[color=blue]
> For many years I have been following the convention of naming all
> class attributes with a leading underscore. This enables me to
> quickly identify the class attributes when I encounter them in the
> source code. Even the GoF book follows this convention, although it's
> true that the GoF book is not an authoritative source for coding
> guidelines.
>
> Recently a colleague remarked that using a leading underscore is a bad
> programming practice that should be avoided at all costs. According
> to her this has to do with the fact that the compiler naming mangling
> procedure also sticks leading underscores and therefore using
> underscores in the source code makes the job of following the
> post-processed source code (should there ever be a need) very
> difficult.[/color]

The point here is to try to convey a certian piece of information, that
the variable in question is a member-variable. I see no reason to use
two characters to convey that information when one will do, so using
underscore + lower case (_variable) or 'm' + upper case (mVariable) both
seem like good options, but combining them into 'm_' seems like a waste.

Having a trailing underscore, (or any sort of trailing character) is
hard to parse for me. Maybe I'm too old school.

But why do we have to convey this particular piece of information? If
the variable is local, then it will be defined right there in the
function and will be obvious. If the variable is global... Well globals
are quite frowned upon aren't they? Maybe it's the global that needs
some special sort of code. Something to think about.

How about this, quite off the wall but interesting idea. Variables that
have a scope smaller than a function should be 1-2 characters long,
varibles with function scope should be 3-4 characters long, variables
with class scope should be 5-6 characters long, variables with file
scope 7-8 chars and variables with multiple file scope should be greater
than 8 characters. Just an idea...
  #9  
Old July 22nd, 2005, 06:13 AM
Nick Hounsome
Guest
 
Posts: n/a

re: Looking for good naming convention for class attributes



"Daniel T." <postmaster@eathlink.net> wrote in message
news:postmaster-FB165D.22233413012004@news06.east.earthlink.net...[color=blue]
> sandeep6699@yahoo.com (Sandeep Sharma) wrote:
>[color=green]
> > For many years I have been following the convention of naming all
> > class attributes with a leading underscore. This enables me to
> > quickly identify the class attributes when I encounter them in the
> > source code. Even the GoF book follows this convention, although it's
> > true that the GoF book is not an authoritative source for coding
> > guidelines.
> >
> > Recently a colleague remarked that using a leading underscore is a bad
> > programming practice that should be avoided at all costs. According
> > to her this has to do with the fact that the compiler naming mangling
> > procedure also sticks leading underscores and therefore using
> > underscores in the source code makes the job of following the
> > post-processed source code (should there ever be a need) very
> > difficult.[/color]
>
> The point here is to try to convey a certian piece of information, that
> the variable in question is a member-variable. I see no reason to use
> two characters to convey that information when one will do, so using
> underscore + lower case (_variable) or 'm' + upper case (mVariable) both
> seem like good options, but combining them into 'm_' seems like a waste.
>
> Having a trailing underscore, (or any sort of trailing character) is
> hard to parse for me. Maybe I'm too old school.
>
> But why do we have to convey this particular piece of information? If
> the variable is local, then it will be defined right there in the
> function and will be obvious. If the variable is global... Well globals
> are quite frowned upon aren't they? Maybe it's the global that needs
> some special sort of code. Something to think about.[/color]

What about file static/unnamed namespace?
I like to use s_ for these and I use them a lot.

I am undecided about class static - where possible I prefer to use file
static instead but where
not I use a prefix - I just can't decide whether to use m_,s_ or something
else.
[color=blue]
>
> How about this, quite off the wall but interesting idea. Variables that
> have a scope smaller than a function should be 1-2 characters long,
> varibles with function scope should be 3-4 characters long, variables
> with class scope should be 5-6 characters long, variables with file
> scope 7-8 chars and variables with multiple file scope should be greater
> than 8 characters. Just an idea...[/color]

variable names should always describe what they are.


  #10  
Old July 22nd, 2005, 06:19 AM
lilburne
Guest
 
Posts: n/a

re: Looking for good naming convention for class attributes


Daniel T. wrote:[color=blue]
>
> The point here is to try to convey a certian piece of information, that
> the variable in question is a member-variable. I see no reason to use
> two characters to convey that information when one will do, so using
> underscore + lower case (_variable) or 'm' + upper case (mVariable) both
> seem like good options, but combining them into 'm_' seems like a waste.
>[/color]

Why is there a shortage of Ms?

We use m_ for members and s_ for statics. However, a_ for
arguments and l_ for locals are IMO warts too far.

Closed Thread


Similar Threads
Thread Thread Starter Forum Replies Last Post
Accessors in Python (getters and setters) mystilleef answers 112 July 21st, 2006 03:55 PM
python-dev Summary for 2005-12-01 through 2005-12-15 Tony Meyer answers 0 January 20th, 2006 04:55 AM
python-dev Summary for 2005-06-16 through 2005-06-30 Steven Bethard answers 2 July 21st, 2005 08:03 AM
Welcome to 'ciwas',this is our FAQ for stylesheet authors v1.16 Jan Roland Eriksson answers 0 July 21st, 2005 01:11 AM