naming convention for class attributes (member data)?

Discussion in 'C++' started by Marco, Dec 20, 2010.

  1. Marco

    Marco Guest

    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?
    Marco, Dec 20, 2010
    #1
    1. Advertising

  2. On 12/20/2010 1:44 PM, 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?


    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
    --
    I do not respond to top-posted replies, please don't ask
    Victor Bazarov, Dec 20, 2010
    #2
    1. Advertising

  3. Marco

    Goran Guest

    On Dec 20, 7:44 pm, 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?


    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").
    Goran, Dec 21, 2010
    #3
  4. Marco

    James Kanze Guest

    On Dec 20, 6:44 pm, 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?


    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
    James Kanze, Dec 21, 2010
    #4
  5. Marco

    James Kanze Guest

    On Dec 20, 7:04 pm, Victor Bazarov <> wrote:
    > On 12/20/2010 1:44 PM, 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?


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

    --
    James Kanze
    James Kanze, Dec 21, 2010
    #5
  6. Marco

    Öö Tiib Guest

    On Dec 21, 12:19 pm, James Kanze <> wrote:
    > On Dec 20, 7:04 pm, Victor Bazarov <> wrote:
    >
    > > On 12/20/2010 1:44 PM, 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?

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


    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.
    Öö Tiib, Dec 21, 2010
    #6
  7. Marco

    Drew Lawson Guest

    In article <>
    writes:
    >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.

    --
    Drew Lawson | Pass the tea and sympathy
    | for he good old days are dead
    | Let's raise a toast to those
    | who best survived the life they led
    Drew Lawson, Dec 21, 2010
    #7
  8. Drew Lawson <> wrote:
    > 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).
    Juha Nieminen, Dec 21, 2010
    #8
  9. Marco

    James Kanze Guest

    On Dec 21, 12:33 pm, Öö Tiib <> wrote:
    > On Dec 21, 12:19 pm, James Kanze <> wrote:


    > > On Dec 20, 7:04 pm, Victor Bazarov <> wrote:


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

    --
    James Kanze
    James Kanze, Dec 21, 2010
    #9
  10. Marco

    Puppet_Sock Guest

    On Dec 20, 1:44 pm, Marco <> wrote:
    [snip]
    > 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
    Puppet_Sock, Dec 21, 2010
    #10
  11. Marco

    Miles Bader Guest

    Juha Nieminen <> writes:
    >> 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).


    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

    --
    We have met the enemy, and he is us. -- Pogo
    Miles Bader, Dec 21, 2010
    #11
  12. Marco

    Bo Persson Guest

    Miles Bader wrote:
    > Juha Nieminen <> writes:
    >>> 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).

    >
    > 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
    Bo Persson, Dec 21, 2010
    #12
  13. On 12/22/2010 2:14 AM, Bo Persson wrote:
    > Miles Bader wrote:
    >> Juha Nieminen<> writes:
    >>>> 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).

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


    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
    Ruslan Mullakhmetov, Dec 22, 2010
    #13
  14. Marco

    Öö Tiib Guest

    On Dec 21, 9:51 pm, James Kanze <> wrote:
    > On Dec 21, 12:33 pm, Öö Tiib <> wrote:
    >
    > > On Dec 21, 12:19 pm, James Kanze <> wrote:
    > > > On Dec 20, 7:04 pm, Victor Bazarov <> wrote:

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


    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.
    Öö Tiib, Dec 23, 2010
    #14
  15. Marco

    BGB Guest

    On 12/20/2010 11:44 AM, 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?




    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...
    BGB, Dec 27, 2010
    #15
  16. On Dec 21, 10:16 am, James Kanze <> wrote:
    > On Dec 20, 6:44 pm, 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?

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



    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.)
    Nick Keighley, Dec 30, 2010
    #16
  17. Marco

    Ian Collins Guest

    On 12/30/10 08:42 PM, Nick Keighley wrote:
    > On Dec 21, 10:16 am, James Kanze<> wrote:
    >> On Dec 20, 6:44 pm, 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?

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

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

    --
    Ian Collins
    Ian Collins, Dec 30, 2010
    #17
  18. On Dec 21, 12:46 pm, "Daniel T." <> wrote:
    > 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 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, Dec 30, 2010
    #18
  19. On Dec 21, 7:04 pm, Juha Nieminen <> wrote:
    > Drew Lawson <> wrote:
    > > 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).


    guk! And this leads to the hungarian madness!

    > > 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).
    Nick Keighley, Dec 30, 2010
    #19
  20. Marco

    James Kanze Guest

    On Dec 30, 7:42 am, Nick Keighley <>
    wrote:
    > On Dec 21, 10:16 am, James Kanze <> wrote:
    > > On Dec 20, 6:44 pm, 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?


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


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

    --
    James Kanze
    James Kanze, Dec 30, 2010
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Rick

    Which c# naming convention?

    Rick, Jan 19, 2004, in forum: ASP .Net
    Replies:
    1
    Views:
    3,761
    Paul Glavich
    Jan 19, 2004
  2. dm1608
    Replies:
    6
    Views:
    8,489
  3. Buck Turgidson

    JSP Method Naming Convention

    Buck Turgidson, Mar 2, 2004, in forum: Java
    Replies:
    1
    Views:
    1,736
    P.Hill
    Mar 2, 2004
  4. Sandeep Sharma
    Replies:
    9
    Views:
    438
    lilburne
    Jan 16, 2004
  5. Peng Yu
    Replies:
    3
    Views:
    1,065
    Simon Forman
    Sep 21, 2009
Loading...

Share This Page