C++ Programming Style

[Noah Roberts]

WEll, I found this one actually to be closer what I like:

http://www.possibility.com/Cpp/CppCodingStandard.html#names

good things there,,, I think better than the first one.

I have to admit to the fact that "count" is not the first thing that
comes to mind when I see a "Cnt" prefix.

 

[Noah Roberts]

WEll, I found this one actually to be closer what I like:

http://www.possibility.com/Cpp/CppCodingStandard.html#names

good things there,,, I think better than the first one.

"Include Units in Names" ->
http://www.possibility.com/Cpp/CppCodingStandard.html#units

We actually include the unit in the type. There are many ways to do it
of course but we've chosen to use the boost::units constructs:

quantity<si:ressure> press;
quantity<si::length> len;
quantity<cgs::length> len2(len); // converted!

It's a MAJOR step up from what this standard is proposing.

 

[Drew Lawson]

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

At one point in my college freshman year, I tried to learn Pascal
without buying the text book. I was guided mostly by compiler error
messages.
Error: line 17, missing semicolon

I ended up spending 6 months thinking that Pascal code was supposed
to have lines starting with semicolons.

That's what the comma-first stuff reminds me of.

 

[Stuart Redmann]

On 31 Mrz., Drew Lawson wrote:

[snip]

At one point in my college freshman year, I tried to learn Pascal
without buying the text book.  I was guided mostly by compiler error
messages.
  Error: line 17, missing semicolon

I ended up spending 6 months thinking that Pascal code was supposed
to have lines starting with semicolons.

That's what the comma-first stuff reminds me of.

LOL, that's a good one (a hearty laugh is a good start into the day).

Now that I've come to think about it, I can't come up with a reason
why every statement should be terminated by a semi-colon other than it
makes things easier for the compiler. Up to this day I have only ever
used one language that doesn't require an explicit "statement
terminator", which is Visual Basic (it uses newlines as terminators,
so it's not a terminator-free language in the purest sense).

Regards,
Stuart

 

[Stuart Redmann]

Noah Roberts wrote:
[snip]

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.

[snip]

Personally, I use the following style: blanks between function name
and parenthesis, comma attached to the word after which it comes.

function (param1,
param2,
param3);

That is what the German Duden (something similar to Webster's
dictionary, I guess) defines as typographic convention for machine-
written documents. Since this style is used for virtually any English
and German prose, I think that computer programs should adopt the same
style. After all, people who read a lot are quite adjusted to this
style, and would find a different style ugly.

Besides, the opening parenthesis provides a nice visual context for
the following parameters (which is another reason why the parenthesis
should be attached to the word inside the parenthesis and not to the
word outside).

However, I disagree with the other style that is suggested in #39: I
prefer the style where the operator is moved to the next line:

totalSum = a + b + c
+ d + e;

or even more detailed:

totalSum = (a + b + c)
* (f + g)
+ h + i;

This is more similar to what one gets teached in 2nd or 3rd grade for
addition of multiple numbers:

2341 totalSum = a
+ 543 + b
+ 182 + c;
------
3066

That's my 2cents.

Regards,
Stuart

 

[crea]

Noah Roberts wrote:
[snip]

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.

[snip]

Personally, I use the following style: blanks between function name
and parenthesis, comma attached to the word after which it comes.

function (param1,
param2,
param3);

I agree, this is how i do as well.

That is what the German Duden (something similar to Webster's
dictionary, I guess) defines as typographic convention for machine-
written documents. Since this style is used for virtually any English
and German prose, I think that computer programs should adopt the same
style. After all, people who read a lot are quite adjusted to this
style, and would find a different style ugly.

Besides, the opening parenthesis provides a nice visual context for
the following parameters (which is another reason why the parenthesis
should be attached to the word inside the parenthesis and not to the
word outside).

However, I disagree with the other style that is suggested in #39: I
prefer the style where the operator is moved to the next line:

totalSum = a + b + c
+ d + e;

or even more detailed:

totalSum = (a + b + c)
* (f + g)
+ h + i;

ye, looks logical.

 

[Goran]

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 )

Ugh...

However, I like,

my_class::my_class(p1, p2, p3, p4)
: m1(p1)
, m2(p2)
, m3(p3)
, m4(p4)
{}

(less finger movement when members are added ;-))

Goran.

 

[crea]

Pascal code is best written by teams of two: one to write the code and one
to write the semicolons.

heh

Pascal was the language they first taught in uni to me back in 1994. Back
then i strugled to understand it...

 

[Joel C. Salomon]

"Include Units in Names" ->
http://www.possibility.com/Cpp/CppCodingStandard.html#units

We actually include the unit in the type. There are many ways to do it
of course but we've chosen to use the boost::units constructs:

quantity<si:ressure> press;
quantity<si::length> len;
quantity<cgs::length> len2(len); // converted!

It's a MAJOR step up from what this standard is proposing.

Actually, the document suggests, "Better yet is to make a variable into
a class so bad conversions can be caught." Better even yet would be to
link to Boost::Units, but the author didn't entirely neglect your point.

--Joel

 

[Bo Persson]

heh

Pascal was the language they first taught in uni to me back in
1994. Back then i strugled to understand it...

Wirth insisted that the semicolon was not a terminator, but a
statement separator. And only to be used where needed.

Moving from Pascal to C, my most common compiler message was:

"Warning: missing semicolon before else":


Bo Persson

 

[Juha Nieminen]

Furthermore "#defines", as you call them should not
be used to define constants.

There are many reasons why that's a good principle: Preprocessor macros
don't obey any scope (in other words, you can't define constants whose
scope is limited to a namespace, class or function), they are untyped
(or perhaps it would be better to say that they are implicitly, rather
than explicitly typed), you can't get their address if needed, and so on.

 

[Noah Roberts]

However, I disagree with the other style that is suggested in #39: I
prefer the style where the operator is moved to the next line:

totalSum = a + b + c
+ d + e;

or even more detailed:

totalSum = (a + b + c)
* (f + g)
+ h + i;

This is more similar to what one gets teached in 2nd or 3rd grade for
addition of multiple numbers:

2341 totalSum = a
+ 543 + b
+ 182 + c;

I find it often beneficial to put the semi-colon on the next line:

total_sum =
a
+ b
+ c
;

Not usually for basic C++ use as shown though. Usually more for things
that end up in long, cascading lines. One example is when I'm
registering several items with a factory or whatever; I have a special
template class that can turn any function call into a DSEL table:

self_returning_fun_wrapper<void(int,int,int)>(bind(&object::call, obj))
// colw colx coly colz
// ===================
( 5, 4, 3, 2 )
( 5, 4, 3, 2 )
( 5, 4, 3, 2 )
;

 

[Rui Maciel]

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.

The latest C++ project I've been working on standardized on .c++ and .h++
extensions.

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

Well, there's the inline keyword.

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

It's only irrelevant if you don't care that the test succeeds or fails. If
we are dealing with some numerical types whose representation of 0 differs
from the binary representation of 0 then your test won't test what you
intended it to test.

Adding to this, comparing floats in terms of equality to a given floating
point literal is a sure way that your code will fail to do what you
intended it to do.

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

To each his own. Personally, I prefer to use a single tab character for
indentation and then let anyone set their text editor to interpret the tab
character as they see fit. If that fails, there is a reason why some
people invested their time developing tools to automatically format the
source code.

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

This was the first time I've ever come across #if 0. Meanwhile, their
stance on comments is widespread to the point that it's also taken
advantage by automatic documentation generators such as Doxygen.


Rui Maciel

 

[Rui Maciel]

My multi-line function headers look like

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

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

Are you paid by the line of code?


Rui Maciel

 

[Noah Roberts]

Jorgen Grahn wrote:

To each his own. Personally, I prefer to use a single tab character for
indentation and then let anyone set their text editor to interpret the tab
character as they see fit.

Text alignment won't match if you do that. Auto formatting fails under
a lot of conditions, especially in C++.

 

[Jorgen Grahn]

True -- that style guide was an example of that.

My multi-line function headers look like

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

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

It *does* have the advantage that to add a param4, I don't have to
touch the param3 line. I hate having two lines in the diff when I just
added one line.

But it looks very strange to me.

/Jorgen

 

[Gerhard Fiedler]

Are you paid by the line of code?

Even if you're not paid by the line of code, this style has its
advantages. Like so:

void
function ( // Short comment about function.
param1 // Short comment about param1.
, param2 // Short comment about param2.
, param3 // Short comment about param3.
) {
...
}

You'll see the short comment when you search for the symbol.

Gerhard

 

[Gerhard Fiedler]

It's only irrelevant if you don't care that the test succeeds or
fails. If we are dealing with some numerical types whose
representation of 0 differs from the binary representation of 0 then
your test won't test what you intended it to test.

In

numeric_type var;
...
assert( !var );

you're testing that the conversion into bool results in false. How do
you know that this isn't what "you" intended to test? For all types
where a conversion to bool is defined in a way that makes sense for this
assertion, it is IMO ok to use it.

Gerhard

 

[Stefan Ram]

void
function ( // Short comment about function.
param1 // Short comment about param1.
, param2 // Short comment about param2.
, param3 // Short comment about param3.
) {
...
}

Not bad, but the parameter declarations are not lined up.
I write this as

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

, one can see that I could add parameter-specific comments
as well, but I believe one would write those comments in
front of the function definition, so that Doxygen can be
used.

I do not call this my »programming style«, it's just my
indentation (bracing) style.

 

[red floyd]

That's how HP Nonstop code is usually written.