Naming conventions

Discussion in 'C++' started by Miguel Guedes, Aug 22, 2007.

  1. Hello,

    Does anyone have a link to the C++ Standard Library naming conventions
    that they could share? I have found a few links to pages on C++ naming
    conventions but am unsure as to what standard they follow.

    Best Regards,

    -- Miguel Guedes

    - X marks the spot for spammers. If you wish to get in touch with me by
    email, remove the X from my address. -
     
    Miguel Guedes, Aug 22, 2007
    #1
    1. Advertising

  2. Miguel Guedes wrote:
    > Does anyone have a link to the C++ Standard Library naming conventions
    > that they could share? I have found a few links to pages on C++ naming
    > conventions but am unsure as to what standard they follow.


    What do you need it for? If you want to know what's allowed to be used,
    get a copy of the Standard, and see what's not allowed; everything else
    would be OK. All names visible to the programmer are defined in the
    Standard already. You're not supposed to add any. If you need to know
    what functions/objects/types exist, get yourself a reference manual.

    V
    --
    Please remove capital 'A's when replying by e-mail
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, Aug 22, 2007
    #2
    1. Advertising

  3. Victor Bazarov wrote:
    > Miguel Guedes wrote:
    > What do you need it for? If you want to know what's allowed to be used,
    > get a copy of the Standard, and see what's not allowed; everything else
    > would be OK. All names visible to the programmer are defined in the
    > Standard already. You're not supposed to add any. If you need to know
    > what functions/objects/types exist, get yourself a reference manual.
    >
    > V


    I'm sorry for not making myself clear, Victor.

    I'd like to adopt standard compliant naming conventions and thought that
    the best way to do it would be to read up on the C++ standard naming
    conventions. Boost.org, for instance, recommends this.

    I found a link [1] but, seeing the standards presented on the page are
    _derived_ from the C++ Coding Standards, I'm unsure what to make of it...


    [1] http://www.nws.noaa.gov/oh/hrl/ihfs/standards/html/C _naming.htm

    --
    Miguel Guedes

    - X marks the spot for spammers. If you wish to get in touch with me by
    email, remove the X from my address. -
     
    Miguel Guedes, Aug 22, 2007
    #3
  4. Miguel Guedes wrote:
    > Victor Bazarov wrote:
    >> Miguel Guedes wrote:
    >> What do you need it for? If you want to know what's allowed to be
    >> used, get a copy of the Standard, and see what's not allowed;
    >> everything else would be OK. All names visible to the programmer
    >> are defined in the Standard already. You're not supposed to add
    >> any. If you need to know what functions/objects/types exist, get
    >> yourself a reference manual.
    >>
    >> V

    >
    > I'm sorry for not making myself clear, Victor.
    >
    > I'd like to adopt standard compliant naming conventions and thought
    > that the best way to do it would be to read up on the C++ standard
    > naming conventions. Boost.org, for instance, recommends this.
    >
    > I found a link [1] but, seeing the standards presented on the page are
    > _derived_ from the C++ Coding Standards, I'm unsure what to make of
    > it...
    >
    >
    > [1] http://www.nws.noaa.gov/oh/hrl/ihfs/standards/html/C _naming.htm


    Ah... Um... All names are lowercase. Multi-word names have words
    separated by underscores (random_shuffle, push_back, find_if). It's
    not as consistent as many would like, though. E.g. "getline" is
    a single "word", no underscores (and there are other examples like
    that).

    Don't get hung up on a specific naming convention. Pick one that is
    convenient and be consistent with it.

    V
    --
    Please remove capital 'A's when replying by e-mail
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, Aug 22, 2007
    #4
  5. Victor Bazarov wrote:
    > Ah... Um... All names are lowercase. Multi-word names have words
    > separated by underscores (random_shuffle, push_back, find_if). It's
    > not as consistent as many would like, though. E.g. "getline" is
    > a single "word", no underscores (and there are other examples like
    > that).
    >
    > Don't get hung up on a specific naming convention. Pick one that is
    > convenient and be consistent with it.
    >
    > V


    Trouble is I have many questions I've not been able to find convincing
    answers to. For instance:

    - When naming pointers should I append a prefix (pName, or p_name), add
    a suffix (name_p) or nothing at all?

    - Should I name namespaces in all-lowercase letters or follow class name
    conventions (all words start with uppercase)?

    - What about global and static variables? Should I append a prefix 'glo'
    and 'sta' respectively, as the guidelines in Boost.org recommend?

    I won't bore you to death. This is just an illustration of how much
    unsure I am when it comes to naming conventions.

    In all honesty, the reason why I started this thread was because I'm
    still using remnants of Microsoft's crippled god-awful hungarian
    notation (professional obligation) and want to completely get rid of all
    the inconsistencies it introduces. So, seeing I'm about to start anew, I
    thought that there's nothing better than to follow _proper_ standards -
    the ones specified in C++ standards.


    --
    Miguel Guedes

    - X marks the spot for spammers. If you wish to get in touch with me by
    email, remove the X from my address. -
     
    Miguel Guedes, Aug 22, 2007
    #5
  6. Miguel Guedes

    Bo Persson Guest

    Miguel Guedes wrote:
    :: Victor Bazarov wrote:
    ::: Miguel Guedes wrote:
    ::: What do you need it for? If you want to know what's allowed to
    ::: be used, get a copy of the Standard, and see what's not allowed;
    ::: everything else would be OK. All names visible to the programmer
    ::: are defined in the Standard already. You're not supposed to add
    ::: any. If you need to know what functions/objects/types exist, get
    ::: yourself a reference manual.
    :::
    ::: V
    ::
    :: I'm sorry for not making myself clear, Victor.
    ::
    :: I'd like to adopt standard compliant naming conventions and
    :: thought that the best way to do it would be to read up on the C++
    :: standard naming conventions. Boost.org, for instance, recommends
    :: this.
    ::
    :: I found a link [1] but, seeing the standards presented on the page
    :: are _derived_ from the C++ Coding Standards, I'm unsure what to
    :: make of it...
    ::
    ::
    :: [1]
    :: http://www.nws.noaa.gov/oh/hrl/ihfs/standards/html/C _naming.htm
    ::
    :: --

    The standard doesn't have a naming convention. Different chapters of
    the standards document have different authors, and they don't agree
    completely either on style or on namning.

    Your link points to two reasonable and widespread conventions,
    lowercase and underscore, or uppercase letters as word separators.
    That gives you either get_line(), or GetLine(). Choose one, and stick
    to it!

    I do not at all believe in using prefixes, like ref or ptr, or using
    an upper or lower case first letter to differentiate between different
    types of objects.


    Bo Persson
     
    Bo Persson, Aug 22, 2007
    #6
  7. Miguel Guedes wrote:
    > Victor Bazarov wrote:
    >> Ah... Um... All names are lowercase. Multi-word names have words
    >> separated by underscores (random_shuffle, push_back, find_if). It's
    >> not as consistent as many would like, though. E.g. "getline" is
    >> a single "word", no underscores (and there are other examples like
    >> that).
    >>
    >> Don't get hung up on a specific naming convention. Pick one that is
    >> convenient and be consistent with it.
    >>
    >> V

    >
    > Trouble is I have many questions I've not been able to find convincing
    > answers to. For instance:
    >
    > - When naming pointers should I append a prefix (pName, or p_name),
    > add a suffix (name_p) or nothing at all?
    >
    > - Should I name namespaces in all-lowercase letters or follow class
    > name conventions (all words start with uppercase)?
    >
    > - What about global and static variables? Should I append a prefix
    > 'glo' and 'sta' respectively, as the guidelines in Boost.org
    > recommend?
    >
    > I won't bore you to death. This is just an illustration of how much
    > unsure I am when it comes to naming conventions.
    >
    > In all honesty, the reason why I started this thread was because I'm
    > still using remnants of Microsoft's crippled god-awful hungarian
    > notation (professional obligation) and want to completely get rid of
    > all the inconsistencies it introduces. So, seeing I'm about to start
    > anew, I thought that there's nothing better than to follow _proper_
    > standards - the ones specified in C++ standards.


    You're a bit mistaken here. The C++ Standard does NOT specify any
    naming convention. It tries to follow some, but isn't doing a good
    job, either.

    Cleaning out inconsistencies is a good goal to have, unfortunately
    it's an unattainable one. Even if you do a piece-meal by collecting
    different conventions from more than one style guide, you will likely
    end up with some sort of inconsistency or two. There is no escape.

    The rule of thumb here is "try to be simple, as simple as possible,
    but not simpler". If you think you need prefices, use them. Which
    ones? Who cares? You just need to be consistent. 'p' for pointers,
    'g' for globals, 'm' for members... It does not matter. The
    Standard Library and the language proper does not use many prefices,
    but it uses suffices, like '_t' for new types (size_t, ptrdiff_t).
    Is that better? Not sure. Not all types have _t on them either.

    Here is my final advice: take _a_ convention and write it down. Try
    to reduce the number of rules you have in your style guide. If you
    can, have no more than, say, five rules. If in the process of
    following your own style guide you find that you need to introduce
    more rules, try to resist the temptation becuase it may mean you'll
    need to review previously written code, where you didn't follow
    the same new rules. IOW, the style guide should be (a) a *guide*
    not a *law*, and (b) *descriptive* more than *perscriptive*.

    V
    --
    Please remove capital 'A's when replying by e-mail
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, Aug 22, 2007
    #7
  8. Miguel Guedes wrote:
    > Victor Bazarov wrote:
    >> Ah... Um... All names are lowercase. Multi-word names have words
    >> separated by underscores (random_shuffle, push_back, find_if). It's
    >> not as consistent as many would like, though. E.g. "getline" is
    >> a single "word", no underscores (and there are other examples like
    >> that).
    >>
    >> Don't get hung up on a specific naming convention. Pick one that is
    >> convenient and be consistent with it.
    >>
    >> V

    >
    > Trouble is I have many questions I've not been able to find convincing
    > answers to. For instance:
    >
    > - When naming pointers should I append a prefix (pName, or p_name), add
    > a suffix (name_p) or nothing at all?
    >
    > - Should I name namespaces in all-lowercase letters or follow class name
    > conventions (all words start with uppercase)?
    >
    > - What about global and static variables? Should I append a prefix 'glo'
    > and 'sta' respectively, as the guidelines in Boost.org recommend?
    >
    > I won't bore you to death. This is just an illustration of how much
    > unsure I am when it comes to naming conventions.
    >
    > In all honesty, the reason why I started this thread was because I'm
    > still using remnants of Microsoft's crippled god-awful hungarian
    > notation (professional obligation) and want to completely get rid of all
    > the inconsistencies it introduces. So, seeing I'm about to start anew, I
    > thought that there's nothing better than to follow _proper_ standards -
    > the ones specified in C++ standards.


    I have a naming convention for you.

    Pick names that mean somthing useful.

    e.g., I don't find it useful to prepend "p" for pointer, but I do find
    it useful to prepend "s_" for static, or "w_" for template parameter or
    "m_" for member variable - but not for function names.

    The convention I usually use is:

    When declaring function parameters do:
    i_ - input
    o_ - output
    io_ - input/output

    Class members:
    t_ - type
    m_ - member
    s_ - static member

    Templates
    w_ - template parameter

    Other decls
    g_ - global variable
    l_ - local variable


    This does help me disambiguate some cases - like:

    struct A
    {
    int m_val;
    A( int i_val ) : m_val( i_val ) {}
    };


    Make sense ?
     
    Gianni Mariani, Aug 22, 2007
    #8
  9. On 2007-08-22 22:41, Miguel Guedes wrote:
    > Victor Bazarov wrote:
    >> Ah... Um... All names are lowercase. Multi-word names have words
    >> separated by underscores (random_shuffle, push_back, find_if). It's
    >> not as consistent as many would like, though. E.g. "getline" is
    >> a single "word", no underscores (and there are other examples like
    >> that).
    >>
    >> Don't get hung up on a specific naming convention. Pick one that is
    >> convenient and be consistent with it.
    >>
    >> V

    >
    > Trouble is I have many questions I've not been able to find convincing
    > answers to. For instance:
    >
    > - When naming pointers should I append a prefix (pName, or p_name), add
    > a suffix (name_p) or nothing at all?


    Use names that makes sense, it's often more important to know what it
    points to than that it's a pointer. Most IDEs can tell you the type of a
    variable but they can not tell you what the value represents.

    > - Should I name namespaces in all-lowercase letters or follow class name
    > conventions (all words start with uppercase)?


    As previously pointed out, the classes etc. in the standard library use
    underscores and not camel-case. Personally I like camel-case better but
    Bjarne Stroustrup claims that underscores have been proven to be more
    readable.

    > - What about global and static variables? Should I append a prefix 'glo'
    > and 'sta' respectively, as the guidelines in Boost.org recommend?


    You should avoid globals :)

    > I won't bore you to death. This is just an illustration of how much
    > unsure I am when it comes to naming conventions.
    >
    > In all honesty, the reason why I started this thread was because I'm
    > still using remnants of Microsoft's crippled god-awful hungarian
    > notation (professional obligation) and want to completely get rid of all
    > the inconsistencies it introduces.


    If you try to get rid of MS's Hungarian notation then why do you try to
    put it back in with prefixing stuff. The original Hungarian notation
    used prefixes to indicate what type of data was stored, not the type of
    the variable used to store them, i.e. szWidth indicates that the
    variable contains the size of something.

    > So, seeing I'm about to start anew, I thought that there's nothing
    > better than to follow _proper_ standards - the ones specified in C++
    > standards.


    There is no formal C++ naming convention used by the standards committee
    (AFAIK) but they do try to keep things consistent but I'm quite sure
    that there are inconsistencies, some due to backward compatibility no
    doubt. If you are looking at for a standard you'll probably have better
    luck looking at Java and .Net, for frameworks that large I'm sure they
    have worked out some standard.

    Get something that feels comfortable and start to write a list of how
    you should name stuff, when you can no longer come up with any more
    cases start using the standard and fix the remaining cases as they come
    up. It does not matter what standard you use, because I can almost
    guarantee that none else will used the same standard, there are always
    some corner cases where they differ.

    --
    Erik Wikström
     
    =?ISO-8859-1?Q?Erik_Wikstr=F6m?=, Aug 22, 2007
    #9
  10. Miguel Guedes

    Bo Persson Guest

    Gianni Mariani wrote:
    :: Miguel Guedes wrote:
    :::
    ::: In all honesty, the reason why I started this thread was because
    ::: I'm still using remnants of Microsoft's crippled god-awful
    ::: hungarian notation (professional obligation) and want to
    ::: completely get rid of all the inconsistencies it introduces. So,
    ::: seeing I'm about to start anew, I thought that there's nothing
    ::: better than to follow _proper_ standards - the ones specified in
    ::: C++ standards.
    ::
    :: I have a naming convention for you.
    ::
    :: Pick names that mean somthing useful.

    Good idea!!

    ::
    :: struct A
    :: {
    :: int m_val;
    :: A( int i_val ) : m_val( i_val ) {}
    :: };
    ::
    ::
    :: Make sense ?

    Personally I don't like all the underscores and little separate
    characters.

    I have a hypothesis that there might be some cultural preferences
    between people using get_line() and GetLine(). Scandinavians and
    germans, for example are very used to create new words by appending a
    number of smaller words. We do that all the time, IRL! English and
    americans do not, and that might make them prefer to write
    lots_of_little_words_with_undescores. I find that hard to read!

    struct A
    {
    int Value;
    A(int Init) : Value(Init) {}
    };



    Bo Persson
     
    Bo Persson, Aug 22, 2007
    #10
  11. Miguel Guedes

    Bo Persson Guest

    Miguel Guedes wrote:
    :: Victor Bazarov wrote:
    ::: Ah... Um... All names are lowercase. Multi-word names have words
    ::: separated by underscores (random_shuffle, push_back, find_if).
    ::: It's not as consistent as many would like, though. E.g.
    ::: "getline" is
    ::: a single "word", no underscores (and there are other examples like
    ::: that).
    :::
    ::: Don't get hung up on a specific naming convention. Pick one that
    ::: is convenient and be consistent with it.
    :::
    ::: V
    ::
    :: Trouble is I have many questions I've not been able to find
    :: convincing answers to. For instance:
    ::
    :: - When naming pointers should I append a prefix (pName, or
    :: p_name), add a suffix (name_p) or nothing at all?

    Think about what that will buy you. Is it important to always know
    that something is a pointer? When you later realize that it should
    have been a reference, will you change the name?

    Pointers are easily recognized as they are used in expressions like
    *Name, or Name->Something.

    ::
    :: - Should I name namespaces in all-lowercase letters or follow
    :: class name conventions (all words start with uppercase)?

    You should probably just use one way of creating names. Otherwise you
    risk getting names that just differs by case.

    namespace car
    {
    class Car;
    }

    Now you have

    car::Car // a type

    Car::Car // a constructor

    Not good!

    ::
    :: - What about global and static variables? Should I append a prefix
    :: 'glo' and 'sta' respectively, as the guidelines in Boost.org
    :: recommend?

    You probably shouldn't use many of these in the first place! :)

    If you need some global configuration settings, for example, you can
    put them in a namespace and get code like:

    if (Global::Config::ShowDebugInfo)
    {
    // display something interesting
    }

    ::
    :: I won't bore you to death. This is just an illustration of how much
    :: unsure I am when it comes to naming conventions.

    So are we. And nobody agrees anyway!

    Use readable names!

    ::
    :: In all honesty, the reason why I started this thread was because
    :: I'm still using remnants of Microsoft's crippled god-awful
    :: hungarian notation (professional obligation) and want to
    :: completely get rid of all the inconsistencies it introduces.

    That was somewhat useful once upon a time, to simulate type checking
    when C types were really just typedefs. In C++ the compiler will tell
    you not to mix two incompatible classes in the same expression.

    :: So,
    :: seeing I'm about to start anew, I thought that there's nothing
    :: better than to follow _proper_ standards - the ones specified in
    :: C++ standards.

    And there aren't any. :-(


    Bo Persson
     
    Bo Persson, Aug 22, 2007
    #11
  12. Gianni Mariani wrote:
    > I have a naming convention for you.
    >
    > Pick names that mean somthing useful.
    >
    > e.g., I don't find it useful to prepend "p" for pointer, but I do find
    > it useful to prepend "s_" for static, or "w_" for template parameter or
    > "m_" for member variable - but not for function names.
    >
    > The convention I usually use is:
    >
    > When declaring function parameters do:
    > i_ - input
    > o_ - output
    > io_ - input/output


    This makes no sense. In my experience the name of the argument is more
    than enough to specify what is I/O and if I really want to go all the
    way - as I am forced to - I document the code as I go using Doxygen's tags.

    >
    > Class members:
    > t_ - type
    > m_ - member


    I've used 'm_' prefixes for class members for far too long and I still
    feel today as I did then when I was forced to adopt this naming scheme -
    that it doesn't improve code readability in the slightest, though it
    does help to avoid ambiguous situations.

    For instance, just now I stepped into this situation:

    class Window
    {
    public:
    bool isMinimized() const;
    bool onFullScreen() const;

    protected:
    bool isMinimized;
    bool onFullScreen;
    }

    Now, do I change the method's names or the attributes'? Obviously I
    ended up changing the attributes' but if I were using the 'm_' prefix
    this would never have been an issue...

    > s_ - static member


    I treat static members as class members, only I declare them in a 'meta'
    section above all class declarations.

    >
    > Templates
    > w_ - template parameter


    I'd rather stick to one single uppercase letter as it stands out well
    enough.

    >
    > Other decls
    > g_ - global variable


    I tend to append the 'g_' prefix, but then again I also refer to global
    variables and functions using the global namespace '::' too, which makes
    the prefix redundant.

    > l_ - local variable


    Why?

    >
    >
    > This does help me disambiguate some cases - like:
    >
    > struct A
    > {
    > int m_val;
    > A( int i_val ) : m_val( i_val ) {}
    > };


    The constructor of A (without modifying the parameter's name) can
    actually be written as:

    A(int val) : val(val) {}

    .... without any warnings being output (in MsVC.)

    >
    >
    > Make sense ?


    Not at all. In my opinion, I would find code written using your naming
    scheme cryptic, hard to read and understand. But then again, people are
    different and I guess if you're using this naming scheme that means you
    must do well with it.


    --
    Miguel Guedes

    - X marks the spot for spammers. If you wish to get in touch with me by
    email, remove the X from my address. -
     
    Miguel Guedes, Aug 22, 2007
    #12
  13. Bo Persson wrote:
    >
    > Think about what that will buy you. Is it important to always know
    > that something is a pointer? When you later realize that it should
    > have been a reference, will you change the name?
    >
    > Pointers are easily recognized as they are used in expressions like
    > *Name, or Name->Something.
    >
    > You should probably just use one way of creating names. Otherwise you
    > risk getting names that just differs by case.
    >
    > namespace car
    > {
    > class Car;
    > }
    >
    > Now you have
    >
    > car::Car // a type
    >
    > Car::Car // a constructor
    >
    > Not good!


    Note taken. I asked that question because STL's namespaces are all in
    lowercase and I think I read a guideline somewhere on the Net.

    >
    > You probably shouldn't use many of these in the first place! :)
    >
    > If you need some global configuration settings, for example, you can
    > put them in a namespace and get code like:
    >
    > if (Global::Config::ShowDebugInfo)
    > {
    > // display something interesting
    > }
    >
    > ::
    > :: I won't bore you to death. This is just an illustration of how much
    > :: unsure I am when it comes to naming conventions.
    >
    > So are we. And nobody agrees anyway!


    He he. Somehow I don't feel as bad!

    >
    > Use readable names!
    >
    >
    > That was somewhat useful once upon a time, to simulate type checking
    > when C types were really just typedefs. In C++ the compiler will tell
    > you not to mix two incompatible classes in the same expression.
    >
    > :: So,
    > :: seeing I'm about to start anew, I thought that there's nothing
    > :: better than to follow _proper_ standards - the ones specified in
    > :: C++ standards.
    >
    > And there aren't any. :-(
    >
    >
    > Bo Persson


    So, I take it the moral of the story is: make up your own naming
    convention and stick to them?



    --
    Miguel Guedes

    - X marks the spot for spammers. If you wish to get in touch with me by
    email, remove the X from my address. -
     
    Miguel Guedes, Aug 22, 2007
    #13
  14. * Miguel Guedes:
    >
    > So, I take it the moral of the story is: make up your own naming
    > convention and stick to them?


    To some degree.

    However, Java and C# have established naming conventions, and to keep
    things as simple as possible it's a good idea to try to use as much as
    practical of the same conventions in all three languages, e.g. "my"
    prefix for (most) instance members, "s" suffix for collection type
    names, camel-case for function names (except if colleagues puke), except
    that Java and C#'s all uppercase for constants is counter-productive in
    C++, where that form should be reserved for macro names, except that
    Java and C#'s "get"-convention is also counter-productive in C++ (I
    guess those counter-productive cases are part of "practicalness").

    There's also another consideration: by /not/ adopting the standard
    library's type name conventions, e.g. don't use "_t" suffix, and /not/
    adopting the Windows API's function name conventions, i.e. don't use
    uppercase first letter for function names, it becomes easier to see
    which names are or are not from the standard library or Windows API.

    Personally I prefer first letter uppercase (Pascal-case) for types and
    having all other names in camel-case, which frees the underscore for the
    places it really can help separate logically distinct name parts, and
    also makes it possible to have "Bananas bananas" without being overly
    creative in trying to come up with some distinct name for the instance.

    For a period I tended to stick a "_" suffix on template names, but I
    can't recollect why I thought that was so splendid an idea.

    --
    A: Because it messes up the order in which people normally read text.
    Q: Why is it such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
     
    Alf P. Steinbach, Aug 22, 2007
    #14
  15. Let me start by saying that there is NO right answer and YMMV.

    Miguel Guedes wrote:
    > Gianni Mariani wrote:
    >> I have a naming convention for you.
    >>
    >> Pick names that mean somthing useful.
    >>
    >> e.g., I don't find it useful to prepend "p" for pointer, but I do find
    >> it useful to prepend "s_" for static, or "w_" for template parameter or
    >> "m_" for member variable - but not for function names.
    >>
    >> The convention I usually use is:
    >>
    >> When declaring function parameters do:
    >> i_ - input
    >> o_ - output
    >> io_ - input/output

    >
    > This makes no sense. In my experience the name of the argument is more
    > than enough to specify what is I/O and if I really want to go all the
    > way - as I am forced to - I document the code as I go using Doxygen's tags.


    I have a very different experience to you then.

    >
    >> Class members:
    >> t_ - type
    >> m_ - member

    >
    > I've used 'm_' prefixes for class members for far too long and I still
    > feel today as I did then when I was forced to adopt this naming scheme -
    > that it doesn't improve code readability in the slightest, though it
    > does help to avoid ambiguous situations.


    exactly. I use many editor features like "highlight all occurrences of
    word under cursor" which makes it very easy to look at a chunk o code
    and understand it better. So, disambiguating is very useful.

    >
    > For instance, just now I stepped into this situation:
    >
    > class Window
    > {
    > public:
    > bool isMinimized() const;
    > bool onFullScreen() const;
    >
    > protected:
    > bool isMinimized;
    > bool onFullScreen;
    > }
    >
    > Now, do I change the method's names or the attributes'? Obviously I
    > ended up changing the attributes' but if I were using the 'm_' prefix
    > this would never have been an issue...
    >
    >> s_ - static member

    >
    > I treat static members as class members, only I declare them in a 'meta'
    > section above all class declarations


    I'm not sure if that is a critique or just an observation ...

    >
    >> Templates
    >> w_ - template parameter

    >
    > I'd rather stick to one single uppercase letter as it stands out well
    > enough.


    That's just it, it does not. When you have a more complex set of
    templates you need template parameter names that make sense.

    >
    >> Other decls
    >> g_ - global variable

    >
    > I tend to append the 'g_' prefix, but then again I also refer to global
    > variables and functions using the global namespace '::' too, which makes
    > the prefix redundant.
    >
    >> l_ - local variable

    >
    > Why?


    Consistantcy and ambiguity resolution.

    >
    >>
    >> This does help me disambiguate some cases - like:
    >>
    >> struct A
    >> {
    >> int m_val;
    >> A( int i_val ) : m_val( i_val ) {}
    >> };

    >
    > The constructor of A (without modifying the parameter's name) can
    > actually be written as:
    >
    > A(int val) : val(val) {}


    Yes, but I'm not doing this for the sake of the compiler.

    >
    > ... without any warnings being output (in MsVC.)
    >
    >>
    >> Make sense ?

    >
    > Not at all. In my opinion, I would find code written using your naming
    > scheme cryptic, hard to read and understand. But then again, people are
    > different and I guess if you're using this naming scheme that means you
    > must do well with it.


    In my opinion, your opinion is unfounded since I have experience
    otherwise that tells me it's easy to use and makes code more readable.

    >
    >
     
    Gianni Mariani, Aug 23, 2007
    #15
  16. Hi!

    Alf P. Steinbach schrieb:
    > Personally I prefer first letter uppercase (Pascal-case) for types and
    > having all other names in camel-case, which frees the underscore for the
    > places it really can help separate logically distinct name parts, and
    > also makes it possible to have "Bananas bananas" without being overly
    > creative in trying to come up with some distinct name for the instance.


    Yes. I agree to this. This matches my preferences. And with Bo's
    hypothesis: I'm German and I don't like names_with_underscores, but I
    like CamelCase.

    > For a period I tended to stick a "_" suffix on template names, but I
    > can't recollect why I thought that was so splendid an idea.


    I see them as regular types, thus they get an uppercase CamelCase name
    which usually names the concept the type needs to implement:
    template<typename RandomAccessIterator> ...

    But I disagree on Bo's namespace example:

    namespace car {
    class Car;
    }

    car::Car //type
    Car::Car //ctor

    I use lowercase namespace names. But this ambiguty has never bitten me.
    Creating a namespace with the same name as a type therein seems to be a
    conceptual error in naming (at least to me).

    Frank
     
    Frank Birbacher, Aug 23, 2007
    #16
  17. Hi!

    Gianni Mariani schrieb:
    > In my opinion, your opinion is unfounded since I have experience
    > otherwise that tells me it's easy to use and makes code more readable.


    How many lines of code does your average function contain?

    Frank
     
    Frank Birbacher, Aug 23, 2007
    #17
  18. Frank Birbacher wrote:
    > Hi!
    >
    > Gianni Mariani schrieb:
    >> In my opinion, your opinion is unfounded since I have experience
    >> otherwise that tells me it's easy to use and makes code more readable.

    >
    > How many lines of code does your average function contain?


    I don't count lines of code in a function so I don't know.

    The idea is that functions are "orthogonal" in terms of functionality.
    If a function gets a little long winded, you should try to see if there
    is any repetition in the code that allows you to break the function down
    to logical "orthogonal" units.

    There are a small set of hard problems that are simply complex logic. I
    don't advocate breaking a complex unit for the sake of breaking it down
    to a set of complex units that make a more complex system than what you
    began with. That means you will occasionally find a function that is
    huge (very occasionally). One that comes to mind was a real-time UDP
    protocol stack. For every packet that came in it needed to deal with
    about 18 cases that were inter-related. That function, while it was
    complex and long really could not be simplified without making the
    "system" more complex, or at least I couldn't come up with a way at the
    time that made any sense to me.

    You'll find an example of code using the naming convention I described
    here and a bunch of functions where you can figure out the average
    length from:

    http://austria.sourceforge.net/dox/html/at__lifetime_8h-source.html

    It's doxygenated so it's missing lots of doxygen comments.
     
    Gianni Mariani, Aug 23, 2007
    #18
  19. Frank Birbacher wrote:
    > Hi!
    >
    > Alf P. Steinbach schrieb:
    >> Personally I prefer first letter uppercase (Pascal-case) for types and
    >> having all other names in camel-case, which frees the underscore for the
    >> places it really can help separate logically distinct name parts, and
    >> also makes it possible to have "Bananas bananas" without being overly
    >> creative in trying to come up with some distinct name for the instance.

    >
    > Yes. I agree to this. This matches my preferences. And with Bo's
    > hypothesis: I'm German and I don't like names_with_underscores, but I
    > like CamelCase.


    I'm neither German nor from an English-speaking country, but I too
    prefer CamelCase over underscoring! I can still remember a few times
    when I had to develop server-side scripting for a few websites in PHP
    and the shock it was to have to use underscoring so as to be consistent
    with the language (PHP uses underscoring.) Not only does it make typing
    slower (in my case), but also I find it impacts slightly on code readbility.

    >
    >> For a period I tended to stick a "_" suffix on template names, but I
    >> can't recollect why I thought that was so splendid an idea.


    Speaking of the '_' character I am currently appending a '_' prefix to
    _private_ class members (attributes/methods) but I'm unsure if it's
    worth the effort. What do you think?

    >
    > I see them as regular types, thus they get an uppercase CamelCase name
    > which usually names the concept the type needs to implement:
    > template<typename RandomAccessIterator> ...


    Good to know it's not against any C++ programmer's standard to adopt
    template type names lengthier than one letter.

    Some of the guidelines on C++ coding styles I found on the net from big
    corporations and research institutes recommend that templates types be
    one uppercase letter, while others advise against it for the sake of
    code readability, etc. This same inconsistency applies to namespaces,
    class attributes and methods, and anything else that involves picking a
    name.

    This lack of a 'standard' among C++ programmers, so to speak, has only
    added to my confusion making it unclear which naming scheme to adopt.

    >
    > But I disagree on Bo's namespace example:
    >
    > namespace car {
    > class Car;
    > }
    >
    > car::Car //type
    > Car::Car //ctor
    >
    > I use lowercase namespace names. But this ambiguty has never bitten me.
    > Creating a namespace with the same name as a type therein seems to be a
    > conceptual error in naming (at least to me).
    >
    > Frank


    Note taken. I was using CamelCase, first letter uppercased, but somehow
    it didn't feel right. You've now given me a logical reason to why not do it.


    Thank you - all the posters who've contributed to this thread - for
    making it all a bit clearer, and easier for me. Hopefully, the
    information contained in this thread will be as useful to others as it
    is to me.

    This newsgroup is without a doubt a source of immense knowledge.


    --
    Miguel Guedes

    - X marks the spot for spammers. If you wish to get in touch with me by
    email, remove the X from my address. -
     
    Miguel Guedes, Aug 23, 2007
    #19
  20. Hi!

    Miguel Guedes schrieb:
    > Good to know it's not against any C++ programmer's standard to adopt
    > template type names lengthier than one letter.


    Well, :) if there is no particular concept the type needs to model I
    will use "T" as the template parameter (assuming value semantics, which
    could be expressed as CopyConstructibleAndAssignable, but that is too
    clumsy). I take this as a consensus just like using "i" as a "for"-loop
    counter. But often enough I also name it "Value". I guess I'm still
    searching for my personal naming convention. ;)

    > This newsgroup is without a doubt a source of immense knowledge.


    :D

    Frank
     
    Frank Birbacher, Aug 23, 2007
    #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. =B=
    Replies:
    4
    Views:
    9,341
  2. Floppy Jellopy

    Namespaces and Naming conventions

    Floppy Jellopy, Jul 20, 2005, in forum: ASP .Net
    Replies:
    4
    Views:
    541
    Kevin Spencer
    Jul 21, 2005
  3. Josh  Wolf
    Replies:
    2
    Views:
    3,286
    Martin Robins
    Mar 31, 2006
  4. Roy  Assaly
    Replies:
    1
    Views:
    478
    Roy Assaly
    Apr 10, 2006
  5. Roedy Green

    naming conventions

    Roedy Green, Jun 29, 2004, in forum: Java
    Replies:
    4
    Views:
    493
    Christophe Vanfleteren
    Jun 30, 2004
Loading...

Share This Page