For completeness, I should discuss the other style rules that I am aware of, but I don't have a strong opinion on one way or the other. All I have to say about them is - if there are multiple choices, pick one and use it consistently.
if( ... ) /* choice 1 */
if ( ... ) /* choice 2 */
Do you put an space after an if, for, while, or do, or not? I prefer to not put the space.
foo( ... ) /* choice 1 */
foo ( ... ) /* choice 2 */
Do you put an space after a function call, or not? I prefer to not put the space.
x = ((y+w)>>3)&5;
if( (a^z) == a+7 )
I parenthesize every sub-expression that involves or bitwise operations. Thus, parenthesize arguments to these operators, and parenthesize the results of these operators if they are sub-expressions. Otherwise, only add parentheses as required.
if( cond1 &&
cond2 ) /* choice 1 */
if( cond1
&& cond2 ) /* choice 2 */
If the control of an if is very long, and consists of a set of conjunctions or disjunctions (i.e. && or ||), then one can either break the line before or after the operator. I prefer to do it before the operator.
In this case there a couple of arguments for doing it the other way; i.e. to break after the &&/||:
These arguments are probably correct; the reasons that I don't do things this way are partly habit, and partly that I don't run into this situation often enough for it to be a problem.
if( x == 0 ) /* choice 1 */
if( 0 == x ) /* choice 2 */
Most people prefer to write 0 == x. The reason stems from the fact that occasionally, people drop one of the =. In that case if the expression ends up looking like:
if( x = 0 ) /* bug, with choice 1 */
if( 0 = x ) /* compile-time error!, with choice 2 */
Thus, by picking choice 2, the bug can be avoided.
I still write x == 0. The only defense I have is habit (I've been doing it forever), training (I'm very careful not to drop the =), and the fact that most syntax checking programs will highlight the expression containing the dropped = even if I do drop it. Its mostly habit, though.