It may be a good idea to choose a code syntax style when learning a new programming language. Here's an overview of what style C and C++ authors follow.

1 Pedantry?

Now, that may be a sign on my part of getting bogged down in things, but I quite like following as closely as possible the style suggested by the people themselves who designed the programming language. However, the authors will usually not include a chapter in their book suggesting one. Worse still, if you spend the time paging through their manual for inspiration, you may soon find that the authors may not always stick to their own style either.

Come to think of it, that may be a good indication that I'm being a little too pedantic about rather futile matters. It's like a painter spending most of his effort and time ensuring that his easel offers an angle of exactly 20° to the canvas, and that its feet are exactly the same distance from each other. Oh, well.

2 Operators

It seems widely accepted that operators should be surrounded by spaces. In fact, it's something I see in the reference manuals of other programming languages too. And yet, when reading other people's code, I more often than not still see compact expressions bereft of any spacing.

double d = 1 + 1; /* Yes */

double d=1+1; /* No */

Of course, this doesn't apply to in-/decrements such as i++ and i--.

3 Curly Braces

Both Kernighan & Ritchie and Stroustrup agree that opening curly braces should be on the same line as a conditional. They use this same style for structures and classes, too:

if (argc != 1) { /* Yes */
    printf("Usage\n");
}

if (argc != 1)
{ /* No */
    printf("Usage\n");
}

struct s { /* Yes */
    int i;
    int k;
};

struct s
{ /* No */
    int i;
    int k;
};

class C { // Yes
    int i;
    int k;
};

class C
{ // No
    int i;
    int k;
};

Conversely, they also both agree that opening curly braces should be in the line following the function declaration:

void g(int i)
{ /* Yes */
    return i;
}

void g(int i) { /* No */
    return i;
}

4 Capitalisation and CamelCasing

In general Kernighan & Ritchie won't use capital letters. Identifier names made of several words will be glued together, all lower case – no CamelCasing. You don't declare getOp(), you call it getop().

Stroustrup will start custom classes with an upper case to point out that it's not a standard type – a sensible practice. But it's not even something he'd be keen on doing for non-standard functions. And he will under no circumstances use CamelCasing although, unlike Kernighan & Ritchie, he might choose to resort to underscores, such as in get_op().

5 Pointers

Kernighan & Ritchie like sticking the * to the variable when declaring points, whereas Stroustrup prefers sticking it to the type. But I this confuses me when it comes to declaring several variables in one go. This declares i as an integer pointer and j as a mere integer, which makes the look of it rather inconsistent:

int* i, j; // Confusing

6 Enough...

... of this futility. Or was it all that futile? Certainly, asking yourself what style to follow and trying to understand other people's may in itself be an interesting exercise. C and C++ are in particular subtle when it comes to pointers, references, their notations and how to season your code with * and &. So maybe we should all go through the question of style at some point.

7 References

• Brian Kernighan and Dennis Ritchie, The C Programming Language
• Bjarne Stroustrup, The C++ Programming Language