«

Nick Keighley <> wrote:
>> * 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).
>
> guk! And this leads to the hungarian madness!

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

On Dec 30, 11:08*pm, Juha Nieminen <nos...@thanks.invalid> wrote:
> Nick Keighley <nick_keighley_nos...@hotmail.com> wrote:
> >> 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).
>
> > guk! And this leads to the hungarian madness!
>
> * 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.

"Bo Persson" <> writes:
>> It seems fine to use names with leading underscore for class members
>> or local variables though.
>
> 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

--
Yossarian was moved very deeply by the absolute simplicity of
this clause of Catch-22 and let out a respectful whistle.
"That's some catch, that Catch-22," he observed.
"It's the best there is," Doc Daneeka agreed.

On Dec 21, 6:44*am, Leigh Johnston <le...@i42.co.uk> wrote:
> On 20/12/2010 18:44, Marco wrote:
>
> > It seems that the most common naming convention for class instance attributes these days (from C++ books) is the trailing underscore. When did this style become the "fashion" leader?
>
> > What member data naming convention are folks using for their C++ production software?
>
> 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

On Thu, 2010-12-30, Ian Collins wrote:
> On 12/30/10 08:42 PM, Nick Keighley wrote:

....
>> class Thing
>> {
>> private:
>> int i_;
>>
>> public:
>> Thing(int i): i_(i)
>> {}
>> };
>>
>> I need different names for the parameter and the member variable.
>
> 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 <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

On Tue, 2010-12-21, James Kanze wrote:
> On Dec 20, 6:44 pm, Marco <prenom_no...@yahoo.com> wrote:
>> It seems that the most common naming convention for class
>> instance attributes these days (from C++ books) is the
>> trailing underscore. When did this style become the "fashion"
>> leader?
>
> 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

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

On Dec 31, 6:07 am, Ebenezer <woodbria...@gmail.com> wrote:
> On Dec 21, 6:44 am, Leigh Johnston <le...@i42.co.uk> wrote:

> > On 20/12/2010 18:44, Marco wrote:

> > > It seems that the most common naming convention for class
> > > instance attributes these days (from C++ books) is the
> > > trailing underscore. When did this style become the
> > > "fashion" leader?

> > > What member data naming convention are folks using for
> > > their C++ production software?

> > 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.

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.

--
James Kanze

On Dec 31, 2:54*am, James Kanze <james.ka...@gmail.com> wrote:
> On Dec 31, 6:07 am, Ebenezer <woodbria...@gmail.com> wrote:
>
>
>
>
>
> > On Dec 21, 6:44 am, Leigh Johnston <le...@i42.co.uk> wrote:
> > > On 20/12/2010 18:44, Marco wrote:
> > > > It seems that the most common naming convention for class
> > > > instance attributes these days (from C++ books) is the
> > > > trailing underscore. When did this style become the
> > > > "fashion" leader?
> > > > What member data naming convention are folks using for
> > > > their C++ production software?
> > > 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.
>
> 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?

On Dec 31, 10:35*am, Leigh Johnston <le...@i42.co.uk> wrote:
> On 31/12/2010 16:24, Ebenezer wrote:
>
>
>
> > On Dec 31, 2:54 am, James Kanze<james.ka...@gmail.com> *wrote:
> >> On Dec 31, 6:07 am, Ebenezer<woodbria...@gmail.com> *wrote:
>
> >>> On Dec 21, 6:44 am, Leigh Johnston<le...@i42.co.uk> *wrote:
> >>>> On 20/12/2010 18:44, Marco wrote:
> >>>>> It seems that the most common naming convention for class
> >>>>> instance attributes these days (from C++ books) is the
> >>>>> trailing underscore. When did this style become the
> >>>>> "fashion" leader?
> >>>>> What member data naming convention are folks using for
> >>>>> their C++ production software?
> >>>> 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.
>
> >> 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?
>
> 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.

On Dec 21 2010, 7:44¬â€*am, Leigh Johnston <le...@i42.co.uk> wrote:
> On 20/12/2010 18:44, Marco wrote:
>
> > It seems that the most common naming convention for class instance attributes these days (from C++ books) is the trailing underscore. When did this style become the "fashion" leader?
>
> > What member data naming convention are folks using for their C++ production software?
>
> 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