Everyone has their own preferred style for writing code. For some programming languages there is common agreement. Java is a good example of such a language. Some languages have wide disagreement. C++ is a good example. Disagreements on how symbol names should be formed, where to put opening braces, etc., can sound almost like religious wars. If you read an assortment of books on programming in C++ it is likely that each author will disagree with all the others and have "good" reasons for his position. Often the point of view will depend on what other languages people have used in the past. Those who "grew up" programming in C tend to have a very different style from those who grew up with Java.
Your future employers, instructors or managers may specify precises guidelines that your code must follow in order to increase consistency of style among members of the team. For this course, you will not be required to follow a specific style. Your instructor may not even follow or agree with these guidelines. (Actually the only reason we don't force you to follow our guidelines is that we can't all agree on what they should be.)
Regardless, all programmers agree that code should be as easy to read as possible and that a consistent style helps makes code easier to read. To that end, I am providing a suggested guideline. If you choose not to follow these guidelines, be sure that your code is consistent and easy to read in whatever style you do use.
BTW, some may notice that these are the same as in Eckel's Thinking in C++. The fact that he has such good style (the same as mine) is one of the reasons I like his book.
Start the name with a lower case letter. If the name consists of more than one word, then each word after the first should start with a capital letter. Example:
thisIsALongVariableOrFunctionName
Every letter should be uppercase. If the name consists of more than one word, then separate the words using the underscore character. Example:
THIS_IS_A_LONG_CONSTANT_NAME
Start the name with an upper case letter. As with variables and funcitons, if the name consists of more than one word, then each word after the first should start with a capital letter. Example:
ThisIsALongStructName
When using a development environment (e.g. .Net), it is likely that the indentation will be managed for you so there is nothing much to discuss. In general, just let your development environment or editor handle the indentation.
However, when you cut-and-paste or otherwise modify code, the indentation will likely get "messed up". Most editors provide an easy way to fix the indentation. In .Net, you select the lines you want to fix and use the keyboard shortcut C-k, C-f. (That means that you hold down the control key and type the keys 'k' and 'f'.) You can find the command on the Edit menu under the item Advanced. (Note that .Net will occasionally get confused and incorrectly indent perfectly reasonable code. Sigh.)
Most everyone agrees that closing braces should go on a line by themselves. But where to put the opening brace?
The main question is do you put the opening brace on a line by itself or leave it on the previous line? For example, with a simple function definition, shall we write as:
void someFunc() { cout << "I like this" << endl; }
or like this:
void someOtherFunc() { cout << "Why use an extra line?" << endl; }
As you may have guessed, I prefer the first approach, but the choice is yours. I use the same style for structs, classes, loops and ifs.
It is amazing how an extra blank space here and there makes it easier for the eye to catch errors. C++ does not require that we put spaces around most constructs, but it sure does makes things easier to read when you do. As an example, take the function someFunc that we defined above, but strip out the "unneeded" whitespace. The result is (more or less):
void someFunc() { cout<<"I don't like this<<endl; }
I would argue that it is hard to look at a piece of code written that way and tell whether anything there was typed incorrectly. Or if there is and error (actually there is), where the error is. Now maybe you don't find this example convincing, but many times students bring me code (or I'm looking at my own broken code) and the use of a little extra whitespace makes the bugs much easier to catch.
Maintained by John Sterling (jsterling@poly.edu).