C++ Programming Style

C

crea

peter koch said:
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?
 
W

werasm

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
 
P

peter koch

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

Goran

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

Jorgen Grahn

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
 
N

Noah Roberts

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!"
 
J

Jorgen Grahn

....

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
 
J

Jorgen Grahn

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
 
N

Noah Roberts

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

Noah Roberts

...

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

Keith H Duggar

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
 
R

RaZiel

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
 
C

crea

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;
}
 
N

Noah Roberts

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

Noah Roberts

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.
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,755
Messages
2,569,537
Members
45,023
Latest member
websitedesig25

Latest Threads

Top