Pages

Sunday, September 26, 2010

Book Review: C++ In Action Industrial Strength Programming Techniques

With all the posts on Agile methodologies I decided to take a break and follow up on more programming aspects. C++ In Action Industrial-Strength Programming by Bartosz Milewski is as the preface states "... is not a language reference or a collection of clever tricks and patterns. This book is about programming." The book offers some useful insights into those programming coming from a C or Java background, but ramps up with some important theory of programming, with useful examples for function pointer routers, techniques for data encapsulation with templates and the windows API.

One of the ideas that struck a chord with me was the case against "defensive programming". Often programmers want to be as careful as possible, but by writing very defensive code, they end up writing nice little places for nasty bugs to hide. Milewski recommends using asserts on parameter input instead of attempting to handle invalid input at all, which in turn prevents bugs from "covering their tracks". He goes on to recommend that programmers do not try and write code that works no matter what. By attempting to write such defensive programming the code becomes more obscure and prone to errors. Instead, programmers should take an approach of validating parameters (and using asserts) and not attempting to handle invalid data by passing on more invalid/garbage data.

I really can get behind this concept, and often will try and write code that does a lot of error checking with quick returns. I find that defensive programming often also goes along with lots of nested if statements and tree logic that ends up complicating the code. The programmer wants to be defensive but does not check the parameters ahead of time, and instead complicates the overall structure of the code. Here are two simple examples of stuff I see all the time. The "Foo" example (below) is not uncommon to see, even though the "Bar" is easier to read and does the exact same thing. By focusing on validating parameters you end up with shorter, cleaner code which is much easier to understand and debug.

// Foo function (with valid inputs do the foo).
int Foo(Object obj, int param1, int param2, bool param3)
{
if(obj != NULL)
{
if(param1 < param2)
{
if(param3)
{
// Do the foo.
return 0;
}
else
{
return -1;
}
}
else
{
return -1;
}
}
else
{
return -1;
}
}

// Bar function (with valid inputs do the foo).
int Bar(Object obj, int param1, int param2, bool param3)
{
if(obj == NULL || param1 > param2 || !param3)
{
return -1;
}

// Do the foo.
return 0;
}

The book is also available at http://www.relisoft.com/book/index.htm and while it does deal with a lot of different elements (like windows specifics, team work and porting code) the end result is an interesting read with some good looks on program transformation and improved structure.

I hope to get more real code examples up soon and will hopefully have some interesting content of my own. But until then I remain...
Michael Hubbard
http://michaelhubbard.ca

No comments:

Post a Comment