Code style

[jaskij]

Hope I don't start a holy war ;)

This question rose to my mind after starting a project with a couple of friends (my very first team project to be honest). We all agreed on CamelCase, but one friend suggested somethin unnatural to me, that is, starting names of all classes and variables of composit data types with capital and of base types with a small letter.
So far I named all classes starting with capitals and variables starting with a small letter.
Although the pros of this he gave were strong (so that it was adopted), it still doesn't sit right with me.

Another disagreement was with braces - where to put them? Since I scan the code more like it is for script languages (like Python), that is ignoring braces and looking only at indentation, I went for the more compact style of putting the opening brace on the same line as the control statement.
Closing one goes - as I see almost everywhere, on it's own line.

Wanted to know what's your take on this guys. How do you do things? How do you indent? How do you name your classes/functions and variables? Why that way?

If anyone is interested, something I found linked on Stroustrup's (I think) page a month or two back, a coding style guidebook from Lockheed Martin: http://www2.research.att.com/~bs/JSF-AV-rules.pdf

[thines01]

It all depends on what you can live with and what agreement you can make.
I am a lone-coder, so I can use whatever suits me.
In a team situation, I guess I would do whatever the senior developer wanted (if I will not be the code owner).

I use a modified Hungarian notation. Braces underneath. Code indented, braces not.

[mike_2000_17]

starting names of all classes and variables of composit data types with capital and of base types with a small letter.

That is very odd indeed. The most important thing about coding conventions, is that they should be conventional. It's like with a standard, it doesn't matter as much how good the standard is, only that everyone adopts it. When it comes to coding style (indentation, CamelCase vs. camelCase vs underscore_separation, brace placements, line lengths, etc. etc.), most books on coding guidelines don't spend much time discussing this, for one good reason: it doesn't matter nearly as much as any of all the other things that you need to agree upon in a team project. As Sutter and Alexandrescu (two giants in C++) would say, "don't sweat the small stuff".

In any case, you do need to agree to a convention. And, in general, it is a good idea to conform to an already existing convention. There is absolutely no point in trying to come up with your own "best" convention, that's just a waste of time. A good convention is just one that everyone is used to and fairly comfortable with, and it also helps if it's simple (no rules like "if a data member is also mutable and a pointer to a const, then it should be prefixed with mpc" or something stupid like that).

In C++, there are a number of different conventions, partly because it is a multi-paradigm language and often, the programming paradigm has a more popular convention. In other (single-paradigm) languages, it tends to be more homogeneous and even standardized; Python and Java come to mind in that regard.

I have seen a lot of code in my time, and there seems to be roughly three dominant conventions (with minor variations in each). The one I use most of the time, and which is predominant in the Boost library and other libraries that focus heavily on generic programming and template meta-programming, is more or less directly taken from the C++ STL library (all names in lower-case, underscore-separated, with template arguments (and concept classes) in CamelCase, and the rest is irrelevant). This is the convention you'll find if you dig into the standard library implementations and similarly, in Boost libraries, and I'm simply harmonizing with it, because it's as good as any convention, so I might as well make my code look the same.

The other common convention is more usual in C++ code that sticks more to the object-oriented paradigm. This convention is basically a calque of the Java convention. This means, CamelCase names for classes (any classes!), camelCase names for member function (usually the first lower-case word is a verb), either camelCase or mCamelCase for data members, and that's about all that matters. Some people like to use the I at the start of a abstract class (or interface) and a C otherwise, I think that's just silly.

The last convention, which is probably not much of a convention, is to program as if you were still programming in C. That is, using long prefixes in every name, as if namespaces didn't exist. Making everything into an accronym just to keep names short, which is an absolutely horrible idea, if there is anything you do need to avoid adopting in your convention, that is it.

I say, if your work is mostly going to be pure OOP, then use the Java-like convention, and don't make too many additional rules or fancy things, keep it simple. If you're going to use a lot of GP amd TMP, then adopt STL-like conventions. Conventions just come with the territory. Keep it simple so that it is easy to comply to, make sure it is a convention that is familiar to you, your team and everybody else in the world. Then, move on and focus on more important things!

Final note, code readability and commenting discipline are not part of the "conventions" I've been talking about. Code readability is just a duty of all programmers, including for example: indenting properly; keeping lines short (about 80-100 characters); giving long and meaningful names to variables, types and functions; putting plenty of spaces between operators in expressions; and, not putting the definitions of long member functions inside the class declaration. Programmers that don't do that are just bad programmers, it's not a matter of conventions or style, just a matter of competence. And commenting discipline is something that you do need to agree to in a project and you do need to keep that discipline (you don't want to have to go through thousands of lines of code to put in comments because you were too lazy to do it at the time when you wrote it). Having good commenting discipline, leading to good and helpful doxygen (or other) documentation, is far more important than the coding conventions.

How do you do things?

If I code my own things, which is mostly in GP and TMP territory, I use a style very close to STL. Otherwise, I adopt whatever convention is used in whatever code I'm working on, it really doesn't matter much to me.

How do you indent?

I usually indent with 2 spaces and I prefer putting the opening curly braces on the same line as the control statement (for more or less the same reason as you). I'm fine with 4 spaces as indentation, but I find that beyond that is a bit far-fetched and worsens the readability of the code. As for braces, one thing I do despise is the style in which the opening and closing curly brace is indented at the same level as the enclosed code (it's just my opinion, I find it very displeasing to the eye).

How do you name your classes/functions and variables? Why that way?

As I said, I comply to STL-like conventions, because that's the convention! The day that I invent some crazy new programming paradigm, I'll come up with an original convention or coding style for it, until then, I remain "conventional". There really aren't any more reasons, there is nothing that makes a convention especially superior to others, just that people adopt it and are used to it. It's a chicken-egg problem, a good convention is one that is widely adopted, and if a convention is widely adopted, it must be good! Right?

[WaltP]

Another disagreement was with braces - where to put them? Since I scan the code more like it is for script languages (like Python), that is ignoring braces and looking only at indentation, I went for the more compact style of putting the opening brace on the same line as the control statement.
Closing one goes - as I see almost everywhere, on it's own line.
How do you indent?

My style is:

    if (comparison)/For()/etc...
    {
        block
        command
        section
    }

Braces on their own line. Everything between indented 4 spaces.
If I end up with 5 or more nested blocks (a very rare occurence) I'll switch to 3 spaces.
I personally find 2 spaces too few.
Indenting one space - why bother?
Anything more than 4 is too far. And NEVER use TABs!!!

Naming stuff -- no hard-and fast convention. Generally:
All CAPS for constants.
WordCase generally for functions
wordCase for variables

[deceptikon]

Although the pros of this he gave were strong (so that it was adopted), it still doesn't sit right with me.

Coding styles are built on good arguments. If you couldn't come up with any cons for his method then there's no reason not to use it. Case in point: I didn't care for Dani's preferred coding style on Daniweb, but it was a reasonable style so I couldn't make any arguments against it that weren't purely personal preference. So we used that style. ;)

Another disagreement was with braces - where to put them?

This is usually the biggest disagreement. The usual advice is to put them anywhere as long as it's consistent, but if you find someone's preferred bracing style so completely difficult to read then it might be a good idea to ask them to change so that the project can get rolling more quickly. For example, the K&R and Allman variants are both widely used and admittedly easy to read:

K&R:

#include <iostream>

using namespace std;

int main() {
    int a[] = {1, 2, 3, 4, 5};

    cout << "Array contents:\n";

    for (int i = 0; i < sizeof a / sizeof *a; ++i) {
        cout << "a[" << i << "] = " << a[i] << '\n';
    }

    cout << "Done.\n";
}

Allman:

#include <iostream>

using namespace std;

int main()
{
    int a[] = {1, 2, 3, 4, 5};

    cout << "Array contents:\n";

    for (int i = 0; i < sizeof a / sizeof *a; ++i)
    {
        cout << "a[" << i << "] = " << a[i] << '\n';
    }

    cout << "Done.\n";
}

But the Whitesmith style is almost universally described as unreadable when one first encounters it:

#include <iostream>

using namespace std;

int main()
    {
    int a[] = {1, 2, 3, 4, 5};

    cout << "Array contents:\n";

    for (int i = 0; i < sizeof a / sizeof *a; ++i)
        {
        cout << "a[" << i << "] = " << a[i] << '\n';
        }

    cout << "Done.\n";
    }

How do you do things? How do you indent? How do you name your classes/functions and variables? Why that way?

I do things the way my employer's coding style requires. :D But my personal style varies. Lately I've been using Allman bracing with a 4 space indent, and fairly conventional whitespace between tokens (as seen above). Previously (and probably still now) I had preferred a variation of K&R[1] with a 4 space indent and conventional whitespace between tokens. Prior to that I used a somewhat unusual whitespace style where nearly every token was separated (except array indexing, which is just weird) and I spent a lot of time writing ad hoc code in the reply box of forums such as this one and as a result favored a 2 space indent.

[1] The variation being essentially Allman bracing for functions and K&R for everything else. I found this easier to read, especially when working with inline member functions in a class.

[DeanMSands3]

I remember some code Mike Abrash had written that (I believe) found its way onto x2ftp. IIRC (If I recall correctly), he used K&R with 3-space indents. I guess when you're Mike frickin' Abrash you can pull quirky stunts like that.

EDIT: I stand corrected. He used Allman. But, yes, his XSharp 3D package v22 from way back in 1992 was written with 3-space C files - BUT the ASM files were written with full tabs.
Link: ftp://ftp.lanet.lv/pub/programming/mirror-x2ftp/source/xsharp22.zip

[triumphost]

Allman style.. the others are so difficult to track which braces match which.. well for me at least.

[two[ ][ ]]

My braces is places like this

function

int main()
{

}

while / for / if /else if / else

while() / do / for() {

}

if() {

} else {

}

AFAIK, This is Linux Kernel Coding Style.

http://www.kernel.org/doc/Documentation/CodingStyle