Papadopoulos Giannis wrote:
Which do you think is best?
1.
a) type* p;
2.
c) return var;
3.
c) return ptr->var;
4.
c) return foo(ptr->var);
5.
c) a = b + c;
6.
a)
type foo(type arg1, type arg2, ...) {
declarations;
code;
return arg1;
}
Style is a very subjective and personal consideration.
C and C++ programmers develop or adopt a style
in order to make their code easier for themselves
and other programmers to read, understand and maintain.
If you are developing your own style, there are no rules
except that you should try to be consistent.
Otherwise, you should try to adopt a style
with which other C and C++ programmers are comfortable,
familiar or that they will at least recognize.
Personally, I try to use the same punctuation rules
that are used for ordinary (mathematical) typesetting.
Here are my recommendations :
Terminators always follow immediately after an expression
x@ for all @ in {?, :, ,, ;}
and are followed by at least one white space.
Write
x? y: z
instead of
x ? y : z
or
x?y:z
and write
void f(int, int, int); void g(double);
instead of
void f(int,int,int); void g(double);
for example.
There is no space
between some binary operators and their operands
x@y for all @ in {::, ., ->, .*, ->*, *, /, %, &, ^, |}
but there is always a space
between other binary operators and their operands
x @ y for all @ in {+, -, <<, >>;, <, <=, >, >=, ==, !=,
&&, ||, =, *=, /=, %=, +=, -=, <<=, >>=, &=, |=, ^=}
except when expressions appear as subscripts.
Write
x + y
instead of
x+y
and
x*y
instead of
x * y
for example.
But you may wish to write
A[i+1][j-1]
instead of
A[i + 1][j - 1]
for example to subscript array A.
Most unary prefix operators never have any whitespace
between themselves and their operands
@x for all @ in {::, ++, --, ~, !, -, +, &, *}
but others do
@ x for all @ in {sizeof, new, delete, delete [], throw}
No unary postfix operators
x@ for all @ in {[], (), ++, --}
ever have any whitespace between themselves and their operands.
Use the normal typesetting rules for parentheses (),
square brackets [], angle brackets <> and curly brackets {}.
No space after (, [, < or { and no space before ), ], > or }.
Write
(x)
instead of
( x )
or
(x )
or
( x)
and write
[x]
instead of
[ x ]
or
[x ]
or
[ x]
for example.
There are, of course, exceptions
where extra white space helps to make your code more readable:
double A[2][3] = {{ 1, -1, 0},
{-10, 11, -21}};
Don't give identifiers cryptic, mangled names.
Use ordinary, meaningful words, conventional symbols
or abbreviations with annotations.
Write
double distance, velocity, acceleration, mass, Force;
Force = mass*accelerati on;
or
double x; // distance
double v; // velocity
double a; // acceleration
double m; // mass
double F; // force
F = m*a;
for example.
Don't rely on defaults. Make declarations explicit.
Write
int i = 1;
instead of
i = 1;
to declare and initialize integer i and write
class X {
private:
// Representation
int I;
public:
// Constructors
// ...
};
instead of
class X {
// Representation
int I;
public:
// Constructors
// ...
};
to define the private data members of class X for example.
Use indentation to emphasize scope.
Everybody is comfortable with standard indentation:
void f()
{
// indent
}
But I indent curly brackets to the scope of the function body:
void f()
{
// indent
}
And I include the open curly bracket with the function heading:
void f() {
// indent
}
to save a line of code.
I always indent just two spaces at a time and
I place just one statement on each line so that
there is usually room for a comment at the end of each line
beginning in column 33 or 41.
Write
if (condition) {
// statements
}
instead of
if(condition) {
// statements
}
and
while (condition) {
// statements
}
instead of
while(condition ) {
// statements
}
to distinguish flow control structures from function calls.
I use
// comment
for comments in C++ and I reserve
/*
a = b;
// comment
b = c;
*/
to comment out code which may include comments.
If you find yourself in an environment
that requires you to conform to style rules with which you are not
comfortable,
consider investing a little time and effort in a program like astyle
Artistic Style
http://astyle.sourceforge.net/
which changes the appearance of C or C++ programs
by inserting or deleting whitespace.
Write
constant == variable
instead of
variable == constant
when comparing a variable to a constant for equality
so that if you write
constant = variable
by mistake, the compiler will detect the error.
I always write
x < y
or
x <= y
instead of
y > x
or
y >= x
when comparing two values so that the expression is true
when the left hand side is to the left of the right hand side
on the real number line.
