C++ Coding Standard Question/Discussion

This is a discussion on C++ Coding Standard Question/Discussion within the C++ Programming forums, part of the General Programming Boards category; Ive been given a coding standard to follow when coding my projects. It is not set in stone yet so ...

  1. #1
    Codebot
    Join Date
    Jun 2004
    Location
    Toronto
    Posts
    195

    C++ Coding Standard Question/Discussion

    Ive been given a coding standard to follow when coding my projects. It is not set in stone yet so I would like to get some 3rd party input (you guys) on some of the rules. Any suggestions are appreciated.

    1. The dereference operator '*' and the address-of operator '&' should be directly connected to the type specifier. The rational of this is that, as an example, int* p; emphasizes type over syntax while int *p; emphasizes syntax over type. Although both forms are valid, the heavy emphasis on types in C++ suggests that int* p; is the preferable form.

    I don't quite agree with this rule because when you concatinate declarations like this:
    Code:
    int *a, *b, *c;
    you are forced to put the operator by the variable instead of the type. Else, you would have to spread all the variables out on its own line:
    Code:
    int* a;
    int* b;
    int* c;

    Whats your take on it. Discuss.
    Last edited by Mastadex; 08-13-2008 at 07:38 AM.
    Founder and avid member of the Internationsl Typo Associateion

  2. #2
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    I personally prefer the form of "one line per variable" anyways, so I'm not sure it's a bad thing.

    Others have suggested that putting the star next to the variable indicates better that the star is referring to the variable itself - so you don't think that
    Code:
    int* a, b;
    produces two pointers. Again, a line [with type] per variable makes it much clearer.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  3. #3
    Ethernal Noob
    Join Date
    Nov 2001
    Posts
    1,901
    U ususally spread out the values instead of doing them inline, unless they are trivial types like ints. It gives me the impression that they are discrete.

    The way I write pointers are the way I read them, from right to left
    int* a means to me "a is a pointer to int". It's just my personal mnemonic.
    Here to Deceive, Inveigle, Obfuscate Since 1945

  4. #4
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,659
    This is Stroustrup's take:
    • Both are "right" in the sense that both are valid C and C++ and both have exactly the same meaning.
    • A ``typical C++ programmer'' writes ``int* p;'' and explains it ``p is a pointer to an int'' emphasizing type. Indeed the type of p is int*. I clearly prefer that emphasis and see it as important for using the more advanced parts of C++ well.
    • Stick to one pointer per declaration and always initialize variables and the source of confusion disappears.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  5. #5
    Ethernal Noob
    Join Date
    Nov 2001
    Posts
    1,901
    A beacon of light in the shroud of darkness that is Stroustrup's C++ book Xp
    Here to Deceive, Inveigle, Obfuscate Since 1945

  6. #6
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,659
    By the way, I am guessing that "the address-of operator '&'" is not the address of operator, but the '&' in the syntax for references.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  7. #7
    Ethernal Noob
    Join Date
    Nov 2001
    Posts
    1,901
    well he called the * the dereference operator which it isn't in that context.
    Here to Deceive, Inveigle, Obfuscate Since 1945

  8. #8
    Codebot
    Join Date
    Jun 2004
    Location
    Toronto
    Posts
    195
    Those are just how I remember them, they may not be the most accurate way to describe it. But that's beside the point. I see why it's useful to use the int* notation. Ugh, its going to be hard to switch.
    Founder and avid member of the Internationsl Typo Associateion

  9. #9
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by Mastadex View Post
    Those are just how I remember them, they may not be the most accurate way to describe it. But that's beside the point. I see why it's useful to use the int* notation. Ugh, its going to be hard to switch.
    You will probably have to get used to using different coding standards than the ones you like sooner or later anyways. It's rare that you can decide completely freely.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  10. #10
    Registered User
    Join Date
    May 2008
    Location
    Paris
    Posts
    248
    Stroustrup has a got a hyperlink to the coding rules for the JSF project. This is really a huge document, which shows that it is not easy to create good rules.

    Badly written, non-consistent or non-complete coding rules will not be respected. Every day experience... so consider studying and (partially) copying these well-written rules instead of writing them yourself.

  11. #11
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    I prefer to separate the terms "coding standard" and "style guideline".
    Too often these two are rolled together into one, but some places break them into separate documents.

    In the 2 document definition, a Coding Standard contains info about best practices to use such as:
    - Always declare and initialize class member variables in the same order.
    - Use smart pointers instead of raw pointers.
    - Make functions const-correct.
    ...

    While a Style Guideline says things that are more arbitrary, but good for maintaining a consistent style in a code base, such as:
    - Line up braces like this:
    Code:
    if ( condition )
    {
       ...
    }
    instead of like this:
    Code:
    if ( condition ) {
       ...
    }
    - Start public member function names with a capital letter and private member functions with a small letter.
    ...

  12. #12
    Codebot
    Join Date
    Jun 2004
    Location
    Toronto
    Posts
    195
    Thanks for the comment but I'm not actually writing the standard. I am just critiquing it. I recently found out that this is a "style" rather then a "standard" thing and we will treat it as that.
    Founder and avid member of the Internationsl Typo Associateion

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Bug in iterator comparison in C++ standard?
    By steev in forum C++ Programming
    Replies: 14
    Last Post: 07-12-2008, 12:02 AM
  2. C/C++ standard
    By confuted in forum A Brief History of Cprogramming.com
    Replies: 3
    Last Post: 07-06-2003, 03:22 AM
  3. C++ Coding Standard
    By confuted in forum A Brief History of Cprogramming.com
    Replies: 6
    Last Post: 05-21-2003, 01:08 PM
  4. Coding Contest....
    By Koshare in forum A Brief History of Cprogramming.com
    Replies: 46
    Last Post: 10-14-2001, 04:32 PM
  5. standard language, standard compiler?
    By doubleanti in forum A Brief History of Cprogramming.com
    Replies: 8
    Last Post: 09-03-2001, 04:21 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21