C++ Programming Style

Discussion in 'C++' started by crea, Mar 30, 2011.

  1. crea

    crea Guest

    crea, Mar 30, 2011
    #1
    1. Advertising

  2. crea

    peter koch Guest

    On 30 Mar., 09:50, "crea" <> wrote:
    > Is this a good c++ style guidance:http://geosoft.no/development/cppstyle.html
    >
    > I am trying to change my style to be constant.


    It can not be recommended. A short glimpse reveals several errors -
    the first one being, that constant identifiers should be all uppercase
    (eg. int MONTHS_PR_YEAR = 12). This is plain wrong - did the author
    come from Java?

    /Peter
    peter koch, Mar 30, 2011
    #2
    1. Advertising

  3. crea

    crea Guest

    "peter koch" <> wrote in message
    news:...
    > On 30 Mar., 09:50, "crea" <> wrote:
    >> Is this a good c++ style
    >> guidance:http://geosoft.no/development/cppstyle.html
    >>
    >> I am trying to change my style to be constant.

    >
    > It can not be recommended. A short glimpse reveals several errors -
    > the first one being, that constant identifiers should be all uppercase
    > (eg. int MONTHS_PR_YEAR = 12). This is plain wrong - did the author
    > come from Java?


    I actually personally like that MONTHS_PR_YEAR . I ve been doing that myself
    normally. And I think many libraries use that style as well? also #defines.
    Like when I used Nokias TETRA class. YOu dont think its usual?
    crea, Mar 30, 2011
    #3
  4. crea

    werasm Guest

    On Mar 30, 10:41 am, "crea" <> wrote:
    > "peter koch" <> wrote in message
    >
    > news:...
    >
    > > On 30 Mar., 09:50, "crea" <> wrote:
    > >> Is this a good c++ style
    > >> guidance:http://geosoft.no/development/cppstyle.html

    >
    > >> I am trying to change my style to be constant.

    >
    > > It can not be recommended. A short glimpse reveals several errors -
    > > the first one being, that constant identifiers should be all uppercase
    > > (eg. int MONTHS_PR_YEAR = 12). This is plain wrong - did the author
    > > come from Java?

    >
    > I actually personally like that MONTHS_PR_YEAR . I ve been doing that myself
    > normally. And I think many libraries use that style as well? also #defines.
    > Like when I used Nokias TETRA class. YOu dont think its usual?


    No, the use of uppercase is reserved for macros.

    Furthermore "#defines", as you call them should not
    be used to define constants. For this you have the
    keyword "const". If libraries use this style, they must
    be quite dated (or perhaps they are not c++ libraries).

    Kind regards,

    Werner
    werasm, Mar 30, 2011
    #4
  5. crea

    peter koch Guest

    On 30 Mar., 10:41, "crea" <> wrote:
    > "peter koch" <> wrote in message
    >
    > news:...
    >
    > > On 30 Mar., 09:50, "crea" <> wrote:
    > >> Is this a good c++ style
    > >> guidance:http://geosoft.no/development/cppstyle.html

    >
    > >> I am trying to change my style to be constant.

    >
    > > It can not be recommended. A short glimpse reveals several errors -
    > > the first one being, that constant identifiers should be all uppercase
    > > (eg. int MONTHS_PR_YEAR = 12). This is plain wrong - did the author
    > > come from Java?

    (should be const int above).
    >
    > I actually personally like that MONTHS_PR_YEAR . I ve been doing that myself
    > normally. And I think many libraries use that style as well? also #defines.
    > Like when I used Nokias TETRA class. YOu dont think its usual?


    The consensus is to use all-uppercase for defines and nothing else. I
    don't know Nokias TETRA class and a quick google did not help, but the
    libraries that I am familiar with do not use the constants must be all-
    upper mentioned in you link.

    /Peter

    /Peter
    peter koch, Mar 30, 2011
    #5
  6. crea

    Goran Guest

    On Mar 30, 9:50 am, "crea" <> wrote:
    > Is this a good c++ style guidance:http://geosoft.no/development/cppstyle.html
    >
    > I am trying to change my style to be constant.


    I like it. But then again, I like all conventions. To me, what's far
    important than the convention itself is that code sticks to it.

    Nitpicks: I prefer NULL over 0 for pointers (it sticks out like a sore
    thumb); I don't mind shortening command to cmd or initialize to init;
    exceptions are generally caught by __const__ reference (point 81).

    Goran.
    Goran, Mar 30, 2011
    #6
  7. crea

    Jorgen Grahn Guest

    On Wed, 2011-03-30, peter koch wrote:
    > On 30 Mar., 09:50, "crea" <> wrote:
    >> Is this a good c++ style guidance:http://geosoft.no/development/cppstyle.html
    >>
    >> I am trying to change my style to be constant.

    >
    > It can not be recommended. A short glimpse reveals several errors -
    > the first one being, that constant identifiers should be all uppercase
    > (eg. int MONTHS_PR_YEAR = 12). This is plain wrong - did the author
    > come from Java?


    I don't think you can call it "wrong". Their rationale is wrong, though:

    "Common practice in the C++ development community."

    Personally I do it that way too, but I'm aware that most people on
    c.l.c++ don't (and you can end up in a flamewar by arguing for it.)

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
    Jorgen Grahn, Mar 30, 2011
    #7
  8. crea

    osmium Guest

    "crea" <> wrote in message
    news:hhBkp.816$2...
    > Is this a good c++ style guidance:
    > http://geosoft.no/development/cppstyle.html
    >
    > I am trying to change my style to be [consistent].


    I just skimmed it and I like it, about 100 style guidelines. If one is going
    to wait for a perfect style book, one is going to wait forever.
    osmium, Mar 30, 2011
    #8
  9. crea

    Noah Roberts Guest

    On 3/30/2011 12:50 AM, crea wrote:
    > Is this a good c++ style guidance:
    > http://geosoft.no/development/cppstyle.html
    >
    > I am trying to change my style to be constant.
    >
    >


    There are many common C++ practices in the "community". Camel case is
    far from the most popular. In fact, using it can get you into trouble
    if you're coding on windows systems.(1,2,6,etc...)

    The all-caps constants thing has been beat to death already.

    Requiring single letter template parameter names is just plain fucking
    stupid. REALLY fucking stupid. (8)

    Requiring variables to be named exactly the same as their type is also
    really fucking dumb. (12)

    Although regarding the example I'd probably agree, the reasoning behind
    15 is only true because they're already being dumbasses via 12.


    Getters and setters are smelly. That this group has an actual naming
    convention for them is dubious. Requiring get/set as prefixes is just
    silly, especially since C++ does overloading.(17)

    Using i,j,k,etc.. for iterator value names is a questionable practice.
    Many people do in fact do it, because it's just easy and fairly well
    recognized, but its a lazy practice and should certainly not be
    recommended/required by a team style guide. Quite frankly, if you find
    yourself using more than just 'i' then you need REAL names for your
    iteration variables. (25)

    Everything about #33 is insane.

    I totally disagree with the examples in #39. COMMA FIRST!

    function( param1
    , param2
    , param3 )

    If you're going to split, do it. Don't mix and match; it's much harder
    to read.

    The exception to #46 should not be allowed.

    #47 should certainly be followed and should go without saying.
    Unfortunately on some teams it does not.

    #57 is dumb. If you have to scroll down to reach the while in a
    do-while then other, more important practices are not being followed
    (keep things short by factoring into smaller functions).

    #60 is just silly.

    All in all this is a terrible style guide. There are some good bits in
    it but too many bad bits and the entire thing is more about formatting
    than about real, important issues. For example, a good style guide
    would say something like:

    "Always assign new pointers to RAII objects immediately and on a single
    line by themselves. Example:

    std::auto_ptr<x_type> x(new x_type);
    std::auto_ptr<y_type> y(new y_type);
    function(x,y);

    // NOT function(std::auto_ptr<x_type>(new x_type), ...);"

    Things like this actually effect the *functionality and correctness* of
    code (works around unknowable order of parameter execution in this
    case), which any good style guide should have as its main focus. This
    guide of yours doesn't even have a single item like this in it.

    This entire guide that you're linking to violates item 0 of "C++ Coding
    Standards" by Sutter & Alexandrescu (a GOOD style guide): Don't Sweat
    the Small Stuff. Almost 100 items of mostly crap because they're too
    worried about whitespace. The entire thing could be summed up in one
    rule: "Make your fucking code make fucking sense to human fucking beings!"

    --
    http://crazycpp.wordpress.com
    Noah Roberts, Mar 30, 2011
    #9
  10. crea

    Jorgen Grahn Guest

    On Wed, 2011-03-30, Noah Roberts wrote:
    > On 3/30/2011 12:50 AM, crea wrote:
    >> Is this a good c++ style guidance:
    >> http://geosoft.no/development/cppstyle.html
    >>
    >> I am trying to change my style to be constant.


    ....

    > I totally disagree with the examples in #39. COMMA FIRST!
    >
    > function( param1
    > , param2
    > , param3 )


    Are you serious? Even if you use that style yourself, surely you know
    almost noone else does?

    ....
    > All in all this is a terrible style guide. There are some good bits in
    > it but too many bad bits and the entire thing is more about formatting
    > than about real, important issues.


    Let me put it this way: there are too many weird things in there; if
    the OP starts following it he'll write code which looks weird. I think
    most people here agree that many of the things the guide calls "common
    practice" aren't common.

    (And in a sibling page about using GNU make to build Java code, they
    show a shell script written in /bin/csh. Those guys *are* weird.)

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
    Jorgen Grahn, Mar 30, 2011
    #10
  11. crea

    Jorgen Grahn Guest

    On Wed, 2011-03-30, Noah Roberts wrote:
    > On 3/30/2011 12:50 AM, crea wrote:
    >> Is this a good c++ style guidance:
    >> http://geosoft.no/development/cppstyle.html
    >>
    >> I am trying to change my style to be constant.
    >>
    >>

    >
    > There are many common C++ practices in the "community". Camel case is
    > far from the most popular. In fact, using it can get you into trouble
    > if you're coding on windows systems.(1,2,6,etc...)
    >
    > The all-caps constants thing has been beat to death already.
    >
    > Requiring single letter template parameter names is just plain fucking
    > stupid. REALLY fucking stupid. (8)
    >
    > Requiring variables to be named exactly the same as their type is also
    > really fucking dumb. (12)

    ....

    You missed a few spectacular ones.

    #34, "... Source files can have the extension .c++ (recommended), .C,
    ..cc or .cpp". I have never, ever seen a source file named foo.c++.
    My editor recognizes it, but that's about it.

    #36, where they seem to forbid inline functions and whatnot because
    "the header files should declare an interface, the source file should
    implement it."

    #53, "Implicit test for 0 should not be used other than for boolean
    variables and pointers." I don't argue with that, but they give the
    rationale "It is not necessarily defined by the C++ standard that ints
    and floats 0 are implemented as binary 0." Surely that's irrelevant
    here, just like it is for the null pointer?

    #71, "Basic indentation should be 2." -- I'm sure a small minority
    prefers that, but I've worked with such code for a few years and I can
    tell it's /stupid/. I have been unable to find anyone at my workplace
    who argues for anything less than 4 (the people being responsible for
    2 having left many years ago).

    #92, use only // for comments, so you can reserve /* */ for commenting
    out huge blocks of code. This is surely Java bias again -- in C++ you
    use #if 0 for such things (or at least I do).

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
    Jorgen Grahn, Mar 30, 2011
    #11
  12. crea

    Noah Roberts Guest

    On 3/30/2011 12:22 PM, Jorgen Grahn wrote:
    > On Wed, 2011-03-30, Noah Roberts wrote:
    >> On 3/30/2011 12:50 AM, crea wrote:
    >>> Is this a good c++ style guidance:
    >>> http://geosoft.no/development/cppstyle.html
    >>>
    >>> I am trying to change my style to be constant.

    >
    > ...
    >
    >> I totally disagree with the examples in #39. COMMA FIRST!
    >>
    >> function( param1
    >> , param2
    >> , param3 )

    >
    > Are you serious? Even if you use that style yourself, surely you know
    > almost noone else does?


    No. But I have noticed that people tend to assume that the way THEY do
    things is the common view.

    --
    http://crazycpp.wordpress.com
    Noah Roberts, Mar 30, 2011
    #12
  13. crea

    Noah Roberts Guest

    On 3/30/2011 12:45 PM, Jorgen Grahn wrote:
    > On Wed, 2011-03-30, Noah Roberts wrote:
    >> On 3/30/2011 12:50 AM, crea wrote:
    >>> Is this a good c++ style guidance:
    >>> http://geosoft.no/development/cppstyle.html
    >>>
    >>> I am trying to change my style to be constant.
    >>>
    >>>

    >>
    >> There are many common C++ practices in the "community". Camel case is
    >> far from the most popular. In fact, using it can get you into trouble
    >> if you're coding on windows systems.(1,2,6,etc...)
    >>
    >> The all-caps constants thing has been beat to death already.
    >>
    >> Requiring single letter template parameter names is just plain fucking
    >> stupid. REALLY fucking stupid. (8)
    >>
    >> Requiring variables to be named exactly the same as their type is also
    >> really fucking dumb. (12)

    > ...
    >
    > You missed a few spectacular ones.
    >
    > #34, "... Source files can have the extension .c++ (recommended), .C,
    > .cc or .cpp". I have never, ever seen a source file named foo.c++.
    > My editor recognizes it, but that's about it.


    These aren't that weird if you're working on Unix, especially with older
    code. The .cpp extension is actually the new one as I understand,
    standardized for little or no more reason than that VS does it.

    > #36, where they seem to forbid inline functions and whatnot because
    > "the header files should declare an interface, the source file should
    > implement it."


    Not bad advice actually. I personally don't go as far as to disallow
    inline functions, but tending toward putting functions in implementation
    files is a good idea. People strongly opposed are often under the
    misconception that it actually makes a difference as far as whether
    something can-be/is inlined by the compiler.

    http://crazyeddiecpp.blogspot.com/2010/12/inline-functions-and-you.html


    > #71, "Basic indentation should be 2." -- I'm sure a small minority
    > prefers that, but I've worked with such code for a few years and I can
    > tell it's /stupid/. I have been unable to find anyone at my workplace
    > who argues for anything less than 4 (the people being responsible for
    > 2 having left many years ago).


    Maybe the people you work with are the stupid ones (see how that
    works?). Using 2 spaces is almost certainly the predominant view out
    there. Most published standards use it. We use it here. AFAICT most
    open source code uses it... There's really no reason for anything more.
    2 is enough to make the indentation quite clear; nothing is gained with 4.

    I do realize there's a wide amount of new developers who never outgrew
    the VS defaults, but to call an opinion that doesn't actually effect
    readability at all "stupid" is pretty fucking stupid.

    > #92, use only // for comments, so you can reserve /* */ for commenting
    > out huge blocks of code. This is surely Java bias again -- in C++ you
    > use #if 0 for such things (or at least I do).


    And if they commonly switch from Java to C++ and back, this makes some
    amount of sense.

    --
    http://crazycpp.wordpress.com
    Noah Roberts, Mar 30, 2011
    #13
  14. On Mar 30, 4:17 pm, Noah Roberts <> wrote:
    > On 3/30/2011 12:22 PM, Jorgen Grahn wrote:
    > > On Wed, 2011-03-30, Noah Roberts wrote:
    > >> On 3/30/2011 12:50 AM, crea wrote:
    > >>> Is this a good c++ style guidance:
    > >>>http://geosoft.no/development/cppstyle.html

    >
    > >>> I am trying to change my style to be constant.

    >
    > > ...

    >
    > >> I totally disagree with the examples in #39.  COMMA FIRST!

    >
    > >> function( param1
    > >>           , param2
    > >>           , param3 )

    >
    > > Are you serious?  Even if you use that style yourself, surely you know
    > > almost noone else does?

    >
    > No.  But I have noticed that people tend to assume that the way THEY do
    > things is the common view.


    My multi-line function headers look like

    void
    function (
    param1
    , param2
    , param3
    ) {
    ...
    }

    So at least one other person besides Noah puts commas first.

    KHD
    Keith H Duggar, Mar 30, 2011
    #14
  15. crea

    RaZiel Guest

    On 30.03.2011 10:41, crea wrote:
    > "peter koch"<> wrote in message
    > news:...
    >> On 30 Mar., 09:50, "crea"<> wrote:
    >>> Is this a good c++ style
    >>> guidance:http://geosoft.no/development/cppstyle.html
    >>>
    >>> I am trying to change my style to be constant.

    >>
    >> It can not be recommended. A short glimpse reveals several errors -
    >> the first one being, that constant identifiers should be all uppercase
    >> (eg. int MONTHS_PR_YEAR = 12). This is plain wrong - did the author
    >> come from Java?

    >
    > I actually personally like that MONTHS_PR_YEAR . I ve been doing that myself
    > normally. And I think many libraries use that style as well? also #defines.
    > Like when I used Nokias TETRA class. YOu dont think its usual?
    >
    >


    I use all uppercase too. It feels the most natural to me. And I come
    from Delphi/C. I avoid using macros as much as possible, and therefore
    all uppercase is only used for constants in my source code.

    - RaZ
    RaZiel, Mar 30, 2011
    #15
  16. crea

    crea Guest

    Class members naming

    This looks logical /good to me, found this doc. So to put "m" before name so
    that it does not conflict with function names!:

    Class Attribute Names
    a.. Attribute names should be prepended with the character 'm'.
    b.. After the 'm' use the same rules as for class names.
    c.. 'm' always precedes other name modifiers like 'p' for pointer.
    Justification
    a.. Prepending 'm' prevents any conflict with method names. Often your
    methods and attribute names will be similar, especially for accessors.
    Example
    class NameOneTwo
    {
    public:
    int VarAbc();
    int ErrorNumber();
    private:
    int mVarAbc;
    int mErrorNumber;
    String* mpName;
    }
    crea, Mar 31, 2011
    #16
  17. crea

    crea Guest

    crea, Mar 31, 2011
    #17
  18. crea

    Ian Collins Guest

    Ian Collins, Mar 31, 2011
    #18
  19. crea

    Noah Roberts Guest

    On 3/30/2011 3:18 PM, Keith H Duggar wrote:
    > On Mar 30, 4:17 pm, Noah Roberts<> wrote:
    >> On 3/30/2011 12:22 PM, Jorgen Grahn wrote:
    >>> On Wed, 2011-03-30, Noah Roberts wrote:
    >>>> On 3/30/2011 12:50 AM, crea wrote:
    >>>>> Is this a good c++ style guidance:
    >>>>> http://geosoft.no/development/cppstyle.html

    >>
    >>>>> I am trying to change my style to be constant.

    >>
    >>> ...

    >>
    >>>> I totally disagree with the examples in #39. COMMA FIRST!

    >>
    >>>> function( param1
    >>>> , param2
    >>>> , param3 )

    >>
    >>> Are you serious? Even if you use that style yourself, surely you know
    >>> almost noone else does?

    >>
    >> No. But I have noticed that people tend to assume that the way THEY do
    >> things is the common view.

    >
    > My multi-line function headers look like
    >
    > void
    > function (
    > param1
    > , param2
    > , param3
    > ) {
    > ...
    > }
    >
    > So at least one other person besides Noah puts commas first.


    I actually picked it up from boost code and Abraham's book on
    TMP....maybe other places. Once I started trying it out I just came to
    find it better. I find it especially important for template
    instantiation sequences, which can get damn illegible if you don't have
    a clear formatting style.

    --
    http://crazycpp.wordpress.com
    Noah Roberts, Mar 31, 2011
    #19
  20. crea

    Noah Roberts Guest

    Re: Class members naming

    On 3/30/2011 4:04 PM, crea wrote:
    > This looks logical /good to me, found this doc. So to put "m" before name so
    > that it does not conflict with function names!:
    >
    > Class Attribute Names
    > a.. Attribute names should be prepended with the character 'm'.
    > b.. After the 'm' use the same rules as for class names.
    > c.. 'm' always precedes other name modifiers like 'p' for pointer.
    > Justification
    > a.. Prepending 'm' prevents any conflict with method names. Often your
    > methods and attribute names will be similar, especially for accessors.
    > Example
    > class NameOneTwo
    > {
    > public:
    > int VarAbc();
    > int ErrorNumber();
    > private:
    > int mVarAbc;
    > int mErrorNumber;
    > String* mpName;
    > }
    >
    >


    This one time I ran into a class like this that had "DrawText" as a
    member function name. Given the naming scheme and the purpose of the
    function it made perfect sense...that is, until I tried using the
    library made this way in a Unicode build. Suddenly I had a bunch of
    warnings about there not being any implementation of "void
    ClassName::DrawTextW".

    This happened on a windows compile of course.

    --
    http://crazycpp.wordpress.com
    Noah Roberts, Mar 31, 2011
    #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. Rob Nicholson
    Replies:
    3
    Views:
    641
    Rob Nicholson
    May 28, 2005
  2. Replies:
    0
    Views:
    2,428
  3. Replies:
    1
    Views:
    776
    Bertilo Wennergren
    Nov 24, 2003
  4. Hardeep Rakhra
    Replies:
    8
    Views:
    622
    Hardeep Rakhra
    Jan 15, 2004
  5. Ken Varn
    Replies:
    0
    Views:
    414
    Ken Varn
    Apr 26, 2004
Loading...

Share This Page