Indent Style - Whitesmiths Style

Whitesmiths Style

The Whitesmiths style, also called Wishart style to a lesser extent, is less common today than the previous three. It was originally used in the documentation for the first commercial C compiler, the Whitesmiths Compiler. It was also popular in the early days of Windows, since it was used in three influential Windows programming books, Programmer's Guide to Windows by Durant, Carlson & Yao, Programming Windows by Petzold, and Windows 3.0 Power Programming Techniques by Norton & Yao. Symbian Foundation continues to advocate this as the recommended bracing style for Symbian OS C++ mobile phone applications.

This style puts the brace associated with a control statement on the next line, indented. Statements within the braces are indented to the same level as the braces.

while (x == y) { something; somethingelse; } finalthing;

The advantages of this style are similar to those of the Allman style in that blocks are clearly set apart from control statements. However with Whitesmiths style, the block is still visually connected to its control statement instead of looking like an unrelated block of code surrounded by whitespace. Another advantage is that the alignment of the braces with the block emphasizes the fact that the entire block is conceptually (as well as programmatically) a single compound statement. Furthermore, indenting the braces emphasizes that they are subordinate to the control statement.

A suggested disadvantage of this style is that the ending brace no longer lines up with the statement it conceptually belongs to. However, the closing brace belongs to the opening brace and not to the control statement.

Additionally, this bracing style shows the logical flow of the code better, in that statements executed in sequence are on the same indentation level, and statements that depend on other statements are indented under them. (This is interpreting the braces as begin-block/end-block markers, and thus begin-block should be indented under the statement controlling its execution).

An example:

if (data != NULL && res > 0) { if (!JS_DefineProperty(cx, o, "data", STRING_TO_JSVAL(JS_NewStringCopyN(cx, data, res)), NULL, NULL, JSPROP_ENUMERATE)) { QUEUE_EXCEPTION("Internal error!"); goto err; } PQfreemem(data); } else if (!JS_DefineProperty(cx, o, "data", OBJECT_TO_JSVAL(NULL), NULL, NULL, JSPROP_ENUMERATE)) { QUEUE_EXCEPTION("Internal error!"); goto err; }

However, if one adopts the styling rule that braces will be provided to every level of 'scope', then the above code could be written to replace the 'else if' with a separated 'if' in the scope of a clearly roped-off 'else' portion of the statement.

if (data != NULL && res > 0) { if (!JS_DefineProperty(cx, o, "data", STRING_TO_JSVAL(JS_NewStringCopyN(cx, data, res)), NULL, NULL, JSPROP_ENUMERATE)) { QUEUE_EXCEPTION("Internal error!"); goto err; } PQfreemem(data); } else { if (!JS_DefineProperty(cx, o, "data", OBJECT_TO_JSVAL(NULL), NULL, NULL, JSPROP_ENUMERATE)) { QUEUE_EXCEPTION("Internal error!"); goto err; } }

Following the strategy shown above, some would argue the code is inherently more readable, however issues arise in readability as more conditions are added, shown in this pseudo-code (although usually in this case, a switch statement would suffice)

else { if (stuff is true) { Do stuff } else { if (other stuff is true) { Do other stuff } else { if (stuff is still not true) { Do even more other stuff } } } }