naming convention for class attributes (member data)?

[Juha Nieminen]

guk! And this leads to the hungarian madness!

How does using the 'm' prefix (as opposed to the '_' prefix) "lead to
hungarian madness"?

 

[Öö Tiib]

  How does using the 'm' prefix (as opposed to the '_' prefix) "lead to
hungarian madness"?

Opposed to underscore suffix. Nothing leads to madness. Usually the
discussions of code style conventions ... just turn into such
emotional "ugly", "confusing", "mad", etc. madness. In practice worst
is lack of consistency. So when gathering team then it is best to
argue, vote and write it down as policy. Whatever strange it is ... if
used consistently the code base feels more uniform.

 

[Miles Bader]

It's technically allowed, but perhaps not "fine".

By "fine", I just meant that there's no language/standards issue with
such usage.

Seeing a leading underscore would make me think "implementation
specific name in the global namespace". Isn't that adding to the
confusion, rather than reducing it?

I dunno. In most code, uses of _actual_ single-underscore-prefixed
"implementation specific names in the global namespace" names seems to
be vanishingly rare, so I'm not sure there's a whole lot of chance for
such confusion to happen in practice (and "in practice" is the
relevant measure here, as obviously it's OK from a pedantic point of
view).

The cases where it does happen seem to be a few well-known
grandfathered-in-from-the-distant-past names, and are almost all
functions rather than variables (e.g., _exit), which makes even them
unlikely to be confused with member variables.

[Note that I'm talking from a gcc/linux perspective; it may be that
things are different in an e.g. ms-windows environment.]

-Miles

 

[Ebenezer]

I use the following:

sFoo    // for static variables
iFoo    // for member variables, "i" stands for "instance"

Taligent used fMemberName -- I think the f was short for field.

aFoo    // for function arguments
foo     // local variables have no prefix

In another recent thread on this topic someone suggested
not putting "warts" on member names but on local variables
since their scope is more limited. I don't have much firm
conviction on this, but think some variation of it is
helpful. I'm experimenting with not adding any distinguishing
characters to class members at this point.


Brian Wood
Ebenezer Enterprises
http://webEbenezer.net

 

[Jorgen Grahn]

On 12/30/10 08:42 PM, Nick Keighley wrote:
....

That example is the classic case where you don't!

The ambiguity arises when you use the member variable in the constructor
body.

That surprises me -- are you really sure, and do you have a reference
handy? I'm not sure you can find it out TC++PL (which is all the
literature I own).

No, don't bother -- a test with gcc makes it clear what's going on.

foo.cc: In constructor 'Foo::Foo(int, int)':
foo.cc:4: error: class 'Foo' does not have any field named 'b'

The i_ in 'Thing(int i): i_(i)' really *does* have to refer to a
member of Thing. It's clearly not just any lvalue, as I guess I
believed.

This is really good news -- I'm frequently annoyed when I have to come
up with unnatural names. Normally I use the foo_ convention for
members so it's not a problem. I don't for struct-like types where all
members are public however, so either I come up with alternate
spellings or abbreviations, or I invert my own rule and use the _
suffix for the parameter name instead.

I will think of this tip as a slightly delayed Christmas gift

/Jorgen

 

[Jorgen Grahn]

Which books? It used to be prevelant, but I've not seen it in
a long time.

IIRC, it's one of two styles mentioned in

%A Trevor Misfeldt
%A Gregory Bumgardner
%A Andrew Gray
%T The elements of C++ style
%I Cambridge University Press
%D 2004

which also says a lot of things I disagree with, but at least it's
recent.

/Jorgen

 

[James Kanze]

Taligent used fMemberName -- I think the f was short for field.

In another recent thread on this topic someone suggested
not putting "warts" on member names but on local variables
since their scope is more limited.

This goes against another rule I've heard: the length of
a variable name should be inversely proportional to its scope.
I regularly use names like i and j for loop indexes (and I'd
definitely not want to prefex them), but no where else.

 

[Ebenezer]

This goes against another rule I've heard: the length of
a variable name should be inversely proportional to its scope.
I regularly use names like i and j for loop indexes (and I'd
definitely not want to prefex them), but no where else.

Jeff Schwab and others have suggested using ii and jj rather
than just i and j. I think that's partly to make variables
easier to pick up. Adding a one character prefix to a one or
two character variable gives a length of two or three. I'm
just trying it out at this point.

Do any impose upper limits for variable lengths?

 

[Ebenezer]

You are trolling.  The number of characters in a variable name is an
irrelevant metric; what is important is to have a meaningful variable
name which has nothing to do with the number of characters modulo any
coding standard requirement to have a prefix.

A compiler may impose an upper limit on symbol name length.

In addition to meaningful names, I would list conciseness as a
priority. I speculate that a limit of 40 characters is helpful.

 

[Keith H Duggar]

I use the following:

sFoo    // for static variables
iFoo    // for member variables, "i" stands for "instance"
aFoo    // for function arguments
foo     // local variables have no prefix

so a constructor for example looks like this:

foo::foo(int aWibble) : iWibble(aWibble) {}

It works quite well (I picked up from when I was a Symbian OS programmer)..

Seems like a nice convention, the one exception being the 'i'.
For me 'm' is better since it is already quite commonly used as
a member prefix, it connotes "me" or "my", and 'i' (paired with
'e') is nice for local iterator pairs. So maybe:

sFoo // for static variables
mFoo // for member variables
aFoo // for function arguments
foo // local variables have no prefix
iFoo // iterator to foo range
eFoo // end iterator of foo range

?

Personally, I do find some prefix convention helpful (and more
so than a suffix convention).

KHD

 

[Nick Keighley]

Yet another bullshit rule Mr Kanze.  

who rattled your cage?

Just because "i" is acceptable as a
local variable name (for loop index) does not suddenly make the
generalization that "variable name should be inversely proportional to
its scope" valid.

struct point
{
        int x;
        int y;

};

yes but the unadorned names aren't available. You have to use
thePoint.x or thePointP->x. And then we're back to discussing the
scope of thePoint rather than the scope of point.

 

[Nick Keighley]

You are trolling.

no he's making a technical point with which you disagree.

 The number of characters in a variable name is an
irrelevant metric; what is important is to have a meaningful variable
name which has nothing to do with the number of characters modulo any
coding standard requirement to have a prefix.

I don't agree. I don't think its a one-to-one mapping but longer names
do get to be a pain and short names invite name space collisions.

A compiler may impose an upper limit on symbol name length.

I worked with someone who liked long names. He ended up with names
that weren't unique because he's exceeded the compiler limit. 31
characters I think

 

[Nick Keighley]

Opposed to underscore suffix. Nothing leads to madness. Usually the
discussions of code style conventions ... just turn into such
emotional "ugly", "confusing", "mad", etc. madness. In practice worst
is lack of consistency. So when gathering team then it is best to
argue, vote and write it down as policy. Whatever strange it is ... if
used consistently the code base feels more uniform.

"using different letters for different types of variables" sounds
excatly like an invitation to hungarian. I've just been introduced to
a large hungarian code base and I'm not enjoying the experience.

 

[Nick Keighley]

no he's making a technical point with which you disagree.

I don't agree. I don't think its a one-to-one mapping but longer names
do get to be a pain and short names invite name space collisions.

Number of characters in a variable name is an irrelevant metric.[/QUOTE]

stalemate by repetition of position

 One
uses named scopes such as classes or namespaces to avoid "name space
collisions".



Sounds like a shit compiler especially if it didn't warn about truncation..

oh it gave an error because the same variable was declared twice, if I
recall correctly. I just find it amazing someone could hit the limit
without really trying. It allowed longer names it just didn't use the
ones past 32 to determine uniqueness

int z_really_really_long_name_a;
int z_really_really_long_name_b;

except they were even longer

 

[James Kanze]

On Dec 31, 2:54 am, James Kanze <[email protected]> wrote:

[...]

Jeff Schwab and others have suggested using ii and jj rather
than just i and j. I think that's partly to make variables
easier to pick up. Adding a one character prefix to a one or
two character variable gives a length of two or three. I'm
just trying it out at this point.

I'm not sure I understand the issue. Any decent editor will
allow searching for a complete word i.

Do any impose upper limits for variable lengths?

Not formally. Common sense seems to suffice in this case
(although I once encountered a programmer who regularly used
names over a 100 characters in length).

 

[Juha Nieminen]

"using different letters for different types of variables" sounds
excatly like an invitation to hungarian. I've just been introduced to
a large hungarian code base and I'm not enjoying the experience.

It's not out of the realm of possibility that you are simply being
prejudiced and not even trying to actually use the naming convention
used in that code to your advantage (ie. to help you read the code
more easily).

 

[Miles Bader]

It's not out of the realm of possibility that you are simply being
prejudiced and not even trying to actually use the naming convention
used in that code to your advantage (ie. to help you read the code
more easily).

It's also not out of the realm of possibility that a meteoroid will
flatten your house in the next day. Still, it seems a poor bet.

-Miles

 

[Jorgen Grahn]

The problem with a trailing underscore is that it makes code visually
more confusing (especially when the underscore is followed by other
symbols such as dots or dashes). Using a letter prefix is less confusing
(and also gives more possibilities, ie. using different letters for
different types of variables).

It's subjective -- which is why we're having this thread over and over
again!

/Jorgen