Tuesday, June 26, 2007

K&R Slaves

Warning: anyone reading this might want to do so with a mental IMHO tag around the whole thing.

Long-suffering friends and colleagues know that I make no secret of disliking the code formatting convention known as K&R style (after Brian Kernighan & Dennis Ritchie and the code layout style first used in their seminal book The C Programming Language). However, although I personally believe that this:

function changeTarget(source){
if (source === Targets.localTarget){
var target = this._get_target(source);

for(i = 0; i < this._log.ops; i++){
if(this._log.ops[i].value === target){
this._logs.selectedindex = i;
}
}
}else{
this._log.selectedIndex = -1;
}

if(this.get_mode() === SourceMode.Extended){
this.addCssClass(this._popupElement, "Extended");
}else{
this.removeCssClass(this._popupElement, "Extended");
}
}


...is much less readable and understandable than this:

function changeTarget(source)
{
if (source === Targets.localTarget)
{
var target = this._get_target(source);

for(i = 0; i < this._log.ops; i++)
{
if(this._log.ops[i].value === target)
{
this._log.selectedindex = i;
}
}
}
else
{
this._log.selectedIndex = -1;
}

if(this.get_mode() === SourceMode.Extended)
{
this.addCssClass(this._popupElement, "Extended");
}
else
{
this.removeCssClass(this._popupElement, "Extended");
}
}

...I know that these things are a matter of preference and project/company standards.


No, what really annoys me are the reasons some people cite for preferring K&R over BSD/Allman code layout and the actual origins of the style itself.


There seem to be two main reasons people go for it - firstly they think it looks cool; as if making code look complicated and involved imparts some sort of geeky kudos - "look at that heavy-duty code! Must be pretty hairy stuff going on in there, best not to touch it or try to maintain it, best just to marvel at it" - however, as in the above examples, I'd go for clarity and readability any day because code shouldn't be "write-only" and needs to be comprehensible to others to allow for maintainability.


The second reason seems to be born of a "be like the big boys" motivation - "if its good enough for the giants of software like Kernighan and Ritchie, then who are we to argue?" and "all the code that comes out of the big guys at Microsoft is formatted that way", but hang on - a few issues:



  • The compacted style only emerged as a practicality of only having 80 column x 25 line displays and trying to get as much readable code into each screen or printed page as possible - we don't have that constraint anymore and who prints code listings these days anyway?

  • Kernighan and Ritchie never mandated or recommended that style - they were quite neutral in the original book about it:


"The position of braces is less important, although people hold passionate beliefs. We have chosen one of several popular styles. Pick a style that suits you, then use it consistently."


Yet somehow the style has become a sort of holy gourd.



  • Kernighan and Ritchie's original use of the style was inconsistent, (again because of constraints); the original C language didn't allow for the compacted braces style on functions that took arguments and K&R were quite happy to be pragmatic about things and adopt a BSD/Allman style for these cases

  • Microsoft's big boys don't always manage consistency either; whilst they ship the AjaxControlToolkit with lots of K&R style code in the JavaScript, their internal style and code review tools warn against elements of K&R styling when they appear in language files that the tools process (main example C#) and it is possible to fall foul of check-in policies for compliance with these code review tools on readability/maintainability grounds

Ultimately though, my point is that to go with K&R for reasons of emulation or hero-worship is spurious and slavish, and readability and comprehensibility are much better criteria by which to select a code formatting style and I will "take the Pepsi challenge" any day that BSD/Allman wins on that score - I might just have to wait for a few others to cast off their chains.

No comments: