IMHO should be favored, as it is the TRUE-PART and/or FALSE-PART which know whether they are complex enough to require multiple statements, and thus a { block }, not the if ( condition ), which does not care.
eg: TRUE-PART may be either
statement1;
or
{
statement1;
statement2;
}
Aligning the braces like so
if ( condition ) {
statement1();
statement2(); }
IMHO should be discouraged, as it suggests that they are a part of the syntax of the if, which they are not.
This generalises to if, for, while, do, functions,...
I read a book once which better explained this. It showed a progressive style of code development, in which nested statements were shown as indented solid black blocks, later filled in by code within the block.
This style of indentation also works best when using line based folding editors, eg:
if ( condition )
x.. TRUE-PART else
x.. FALSE-PART
(Note: x.. should read..., but if I type this, the formatting messes up).
Slashdot Mirror
if ( condition )
TRUE-PART
else
FALSE-PART
IMHO should be favored, as it is the TRUE-PART and/or FALSE-PART which know whether they are complex enough to require multiple statements, and thus a { block }, not the if ( condition ), which does not care.
eg: TRUE-PART may be either
statement1;
or
{
statement1;
statement2;
}
Aligning the braces like so
if ( condition )
{
statement1();
statement2();
}
IMHO should be discouraged, as it suggests that they are a part of the syntax of the if, which they are not.
This generalises to if, for, while, do, functions, ...
I read a book once which better explained this. It showed a progressive style of code development, in which nested statements were shown as indented solid black blocks, later filled in by code within the block.
This style of indentation also works best when using line based folding editors, eg:
if ( condition )
x.. TRUE-PART
else
x.. FALSE-PART
(Note: x.. should read ..., but if I type this, the formatting messes up).
http://www.superliminal.com/pfractal.htm has an interesting representation, dating back to 1995.