Pro .NET 2.0 Code and Design Standards in C#

Mark Horner takes on the ambitious project of telling us how to standardize code, design, and patterns in “Pro .NET 2.0 Code and Design Standards in C#” published by Apress.  A what, where, why and how format for each topic promised the reasoning and justification for the standard practices.  I had high expectations for a clear explanation of a proposed standard for designing and developing applications in C#.  This book misses the mark and left me wondering what standard was being proposed.

As I read through the book, I kept wondering why the material I had just read was included in the book.  For example, in a book about C# standards the author discusses Visual Basic naming conventions, and even demonstrates the use of a leading underscore for a variable name with Visual Basic code.  The author makes confusing claims such as “…there is always an option to accept a .NET standard, which rules against using case sensitivity (e.g. in C# language).”  The syntax of basic language structures is covered, such as an if statement, including the optional else clause.

The what, where, why and how format of each topic is followed by an acknowledgement of the practice.  Apparently believing the first acknowledgement isn’t enough, a List of Standards is included in the back of the book where the acknowledgements are repeated.

The purpose of the book seems to be mentioning as many topics as possible, whether or not they have anything to do with standards.  For instance, the author felt the need to include the first 128 ASCII characters and parentheses in the glossary but not tell you their purpose.  The entire entry for parentheses is
()     Parentheses.

Compare that to the much more enlightening
‘     Single quote – not a comment (“//” or “/*…*/”).

The weight given topics seems strange as well, with the if statement getting about the same coverage as service oriented architecture, about two pages each.  Based on the title, I expected to see a standard developed.  What a surprise.  At the end of the day what we are left with is not a standard at all, but just acknowledgements that various things exist.  

Maybe I’ve just had my expectations set too high by the excellent “Framework Design Guidelines” by Krzysztof Cwalina and Brad Abrams, but Horner’s book is a big disappointment.  Save your money.