naming convention for class attributes (member data)?

[Marco]

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?

 

[Victor Bazarov]

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?

Probably at about the same time as it became fashionable to bash MS for
their "Hungarian notation" and their leading 'C' for classes and 'm_'
for members...

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

It probably varies from group to group, but I wouldn't be surprised if
most (more than 50%) Windows folks use 'm_' prefix for member data in
their software.

Let me ask you, though, why do you care?

V

 

[Goran]

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?

Who cares? Doesn't matter!

Goran.

P.S. member_ (gcc), m_tpMember (MS, and tp stands for "type prefix"),
FMember (Borland, "F" is for "field").

 

[James Kanze]

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.

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

The most frequent I've seen is an m_ prefix (with s_ for static
members); I've also seen my (with our for statics), and code
which doesn't use any special mark. (In an ideal world, no
special convention should be necessary. The name of the
variable would say enough about it that you'd just know. In
practice, I've not seen a team where everyone was that good at
naming, however, and some convention certainly helps then.)

 

[James Kanze]

On 12/20/2010 1:44 PM, Marco wrote:

Probably at about the same time as it became fashionable to bash MS for
their "Hungarian notation" and their leading 'C' for classes and 'm_'
for members...

Neither are what I'd call Hungarian, and as far as I know, no
one has bashed Microsoft for using a leading C for MFC classes
(in the absense of namespaces when they developed them). What
people do object to is users who put a leading C everywhere,
since that prefix does indicate that the class is in MFC.

 

[Öö Tiib]

Neither are what I'd call Hungarian, and as far as I know, no
one has bashed Microsoft for using a leading C for MFC classes
(in the absense of namespaces when they developed them).  What
people do object to is users who put a leading C everywhere,
since that prefix does indicate that the class is in MFC.

Yes, but Victor did name them as three different decorations of
MicroSoft not as same. I remember plenty of bashing against "Hungarian
notation", first it was ugly itself and while original notation was
for attributing usage of variable MS did indicate type with it.

Using leading C (of MFC) in your own classes feels like using prefixes
Q (of QT) or WX (of wxwidgets) in your own classes, but Visual Studio
code generators and wizards encourage to use C in your own classes.
That was also seriously frowned upon.

None bashing i remember about m_ prefix, but I have also picked up
that trailing underscore for private data members. MS m_ prefixed data
members were often public, I have none as rule. The best idea is
perhaps to agree it with team and to follow what was agreed. It is
cheap to statically check (and even convert between) such conventions.

Oh .... and because concurrency has gone into big fashion static data
members are quite out of fashion. These cause similar synchronization
overhead and scalability issues as all sorts of other singular state.

 

[Drew Lawson]

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 originally scoffed at any such notations. But over time, I've
fallen in with the trailing underscore. When I'm looking at code
that isn't fresh, it is helpful to me to see that a symbol is in
the instance, so I don't get annoyed at not being able to see the
declaration.

As for what I *see* most often, well that would be the leading
underscore. It's like a meme or a code style virus. I see it
everywhere and have (usually) given up on pointing out why it is
ill advised.

 

[Juha Nieminen]

I originally scoffed at any such notations. But over time, I've
fallen in with the trailing underscore. When I'm looking at code
that isn't fresh, it is helpful to me to see that a symbol is in
the instance, so I don't get annoyed at not being able to see the
declaration.

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

As for what I *see* most often, well that would be the leading
underscore. It's like a meme or a code style virus. I see it
everywhere and have (usually) given up on pointing out why it is
ill advised.

Should suffice to say that the C++ standard frowns on the programmer
using it (IIRC).

 

[James Kanze]

Oh .... and because concurrency has gone into big fashion static data
members are quite out of fashion. These cause similar synchronization
overhead and scalability issues as all sorts of other singular state.

Really. Everyone I know still prefers "static int const size
= 42;" over "#define SIZE 42". (In other words, there's static,
and there's static.)

 

[Puppet_Sock]

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

Naming conventions are only important when you
are in a team. In that case, you should get
together with your team and decide what to do.
It's important to keep the team as happy as
can be easily achieved. If a trivial thing
like agreeing on a naming convention will
decrease arguments, I say go for it.

Personally, I can deal with just about any
sensible naming convention. The only things
I will object to are things that interfere
with standard library or compiler convnetions.
If a thing created by the development team
(variable, object, function, class, namespace,
etc. and so on) *looks* like it is one of the
things that "comes with" the compiler, then
I object that it is confusing.

But beyond that, hey. We have good text editors
built into most development environments. I can
deal with a naming convention.
Socks

 

[Miles Bader]

Should suffice to say that the C++ standard frowns on the programmer
using it (IIRC).

Does it?

My vague understanding:

+ Names that contain a double underscore (__foo, foo__bar) or begin
with an underscore followed by a capital letter (_Foo), are always
reserved for compiler/system use

+ Any name in the global namespace with a leading underscore is
reserved for compiler/system use

It seems fine to use names with leading underscore for class members
or local variables though.

-Miles

 

[Bo Persson]

Does it?

My vague understanding:

+ Names that contain a double underscore (__foo, foo__bar) or begin
with an underscore followed by a capital letter (_Foo), are
always reserved for compiler/system use

+ Any name in the global namespace with a leading underscore is
reserved for compiler/system use

It seems fine to use names with leading underscore for class members
or local variables though.

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

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?


Bo Persson

 

[Ruslan Mullakhmetov]

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

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?


Bo Persson

As for me I found using leading underscore on class data-members
(which i presume to be always private) very useful, because it helps
distinguis globals (if you have them) and local vars from data-members.
Another techniques i found either tedious like m_ (more switches) or not
clear like iMember, where i could stands for integer or instance.

Also i haven't yet fallen into ambiguity with implementation
specific names, probably because they are in global namespace scope.

It would be interesting if would be any way to force using this on
some members. I don't know how to get such effet in current c++ but it
could be interesting for example to allow 'explicit' word on
data-members so they will be needed to be explicitly pointed by this.

Ex.

class Foo {
int im_member; // implicit
explicit int ex_member; // explicit
public:
void bar()
{
im_member = 0; // ok.
this->ex_member = 0; // ok.
ex_member = 0; // compilation error.
}
};

BR, RM

 

[Öö Tiib]

Really.  Everyone I know still prefers "static int const size
= 42;" over "#define SIZE 42".  (In other words, there's static,
and there's static.)

Yes, me too. However when it is an integral constant then i usually
use naming convention of integral constants, not static members. I
prefer PascalCase for integral constants. I use PascalCase with types
too; it is rare when reader does not get if it is integral constant or
type.

With my remark i meant mutable singular state that is causing
headaches and so is better to hide as implementation detail. Hidden
details are simpler to replace when they turn into some scalability or
synchronization bottle-necks. I lack special naming convention for
static data members since i want to get rid of them.

 

[BGB]

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?

for classes:

CamelCase, usually public methods (or properties in C# or similar);
camelCase, usually fields or private methods (except in Java, where this
is often the case for methods in general).

"z_" or "Z_" usually a "don't use" prefix (means this name is internal,
so avoid using even if public, as it is probably public due to technical
reasons...).

I usually don't distinguish between static/non-static fields or methods
(hadn't thought of it).

CamelCase is also used for class names, and ICamelCase often for
interfaces (or abstract base classes).


I may use:
something_subname

for fields or methods if there are a bit too many, or they are unrelated
or are a single conceptual unit.

sometimes a suffix such as "_f" is used for function pointers and similar...


in C and for top-level functions (I don't often use namespaces, as they
clash with my auto-header tools):

LIBRARY_CapsFirst, internal functions, library-specific;
LIBRARY_Component_CapsFirst, internal functions, component specific.

generally, it is ill-advised to use functions with the above naming
(they are internal APIs).

library_alllowercase
library_component_alllowercase
library_camelCase
....

is usually used for top-level variables (generally to be avoided if
possible) and also for library utility functions or often static-inline
functions. sometimes with the above, special suffixes such as "_r" or
similar are used to indicate special behavior ("_r" is typically a
recursive function).

I don't use public global variables, as this is nasty, so all shared
globals either need to be imported explicitly, or more typically
accessed via API calls...


libCamelCase, is typical for public API functions.


or such...

 

[Nick Keighley]

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


The most frequent I've seen is an m_ prefix (with s_ for static
members); I've also seen my (with our for statics), and code
which doesn't use any special mark.  (In an ideal world, no
special convention should be necessary.

how about constructors?

class Thing
{
private:
int i_;

public:
Thing(int i): i_(i)
{}
};

I need different names for the parameter and the member variable.

The name of the
variable would say enough about it that you'd just know.  In
practice, I've not seen a team where [not?] everyone was that good at
naming, however, and some convention certainly helps then.)

 

[Ian Collins]

how about constructors?

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.

 

[Nick Keighley]

I don't know about "folks," but in my last C++ shop, no special mark was
used for member-variables. If you wanted to name a parameter the same as
a member-variable, the parameter got a trailing underscore. For example:

class Foo {
   int bar;
public:
   void setBar(int bar_) {
      bar = bar_;
   }
};

I've always preferred the header file stuff to be "clean" and easily
readable so I'd rather mark the definition rather than the
declaration.

Though I tend to reverse this for POD-like structs

struct Stuff
{
T first;
T second;
};

Which is kind of consistent as first and second are visible to the
client

 

[Nick Keighley]

  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!

 

[James Kanze]

how about constructors?

class Thing
{
private:
int i_;

public:
Thing(int i): i_(i)
{}
};

I need different names for the parameter and the member variable.

class Thing
{
private:
int i;
public:
Thing(int initialI) : i(initialI) {}
};

If you're sufficiently explicit with your naming convention,
there should never be any need for a special convention. The
global convention would be an unqualified substantive for types,
and a qualified substantive for variables, so the member might
be "currentState", and the parameter "initialState" (ctor) or
"newState" (mutator functions).

In practice, I've yet to encounter anyone who was systematically
sufficiently explicit, and the special convention does prove
convenient. But I recognize that it is only because we are
human, and not perfect (at naming, in this case).