Book Review: Code Complete 2nd ed by Steve McConnell

Code Complete Second Edition, A practical handbook of software construction, Steve McConnell, Microsoft Press, ISBN 0-7356-1967-0.

Code too Complete? The emphasis in this book is said to be practicality, as opposed to academic and theoretic articles. However, it's apparent that Steve McConnell lost track of that goal and perhaps really wants to be a real academic software hotshot, like Edsger Dijkstra. The book is 862 pages, not including 21 (twenty-one) pages of bibliograhpy citing approximately 450 references.

Just about every statement in the book has a reference (McConnell 2004). There are literally hundreds of citations of various research results, all which goes to prove the various points the author wants to make. Did you for example know that researches have found that the optimal number of white space in indentation lies between 2 and 4 spaces? (Miaria et al. 1983). Do you really care that much that you want a reference to a detailed study?

Code Complete suffers greatly from an attempt to be too precise - it's not a bad thing per se to be careful in keeping opinions and researched facts apart. But too much of a good thing can actually hide the important message that's there. And there is one! Code Complete should perhaps be labelled 'Catalog Complete' - because it is a pretty much complete catalog of proven software construction practices, and that's a very good thing, as it goes.

Looking behind the veils of the semi-academic format, Code Complete does indeed contain an enormous amount of information and good advice on how to construct great software. There is absolutely nothing new in this book, this is not a landmark that will be referenced like the beginning of something new in the future, it's a statement of the current state of the art. However, since it's also a fact (reference ignored) that the majority of current software projects and current software developers do not work at the level of the current state of the art, it's very useful to get a complete exposé like this for some, but not all.

I read this book cover-to-cover, every page, every word (except some cross-references in the margins). Don't do that. Skim it, browse it, and stop and read when you find something of personal interest.

Code Complete should probably be read by first-line software development managers and developers with 10 years plus of experience. I really don't think that it's useful for less senior people. There are sure to be more accessible and inspring texts on the subject matter, all of which likely are referenced in Code Complete. So if you're a manager or a senior designer or architect, read it, pick your 10 favorite things from it, make a note of references that sound relevant for your co-workers and then go out and buy them those.

Book Review: ASP.NET 2.0 Security by Stefan Schackow

The full title of this nice not so-little tome reads 'Professional ASP.NET 2.0 Security, Membership, and Role Management', by Stefan Schackow, published by Wrox, Wiley Publishing, Inc. ISBN 978-0-7645-9698-8.

Let's get one thing clear first - Stefan will never get a Nobel prize. This may well be the most boring book I've ever read, it's also full of small typos and minor editorial mistakes. At the same time - it's one of the more readily useful ones too. I read this book cover-to-cover, like I do practically all such books. This might not be the recommended way to get the most fun out of it, however, it's still something that must be done.

Let's get the other thing clear - If you ever think about implementing, extending or otherwise do any kind of real-world application using the ASP.NET 2.0 membership, profile and role providers you need to read this book. The documentation and SDK will not suffice. You may get something that appears to work, but you're missing out on all the little details that will make for really robust and secure code.

Stefan covers with absolutely mind-numbing detail just what actually happens in ASP.NET when a request is authenticated and how authorization uses the identities in all the various scenarios, depending on which IIS version, what kind of impersonation is in effect, what kind of authentication is used etc. This is absolutely essential information, that I've never seen collected like this. I used to work for a leading supplier of content management systems, and the support was constantly plagued by hard-to-debug cases with security related problems. How I wished that I'd read this book then...

After this almost bottom-less dive into the details of the fundament, Stefan continues to cover just how the membership, profile and role providers are architected, how they are intended to be used, interspersed with anectdotes from the development with rationales for various strangenesses that is left in the final product etc. Intermixed are various code samples with how-to recipes to achieve various neat functions by wrapping or extending the providers supplied with ASP.NET.

It's not an inspiring book in the most common sense, but as one manager once told me 20 years ago when he handed me my very own copy of "System 370 Job Control Language" - it's required reading. (It should be noted that I was employed as a Unix/C developer at that time - I still don't know what he was thinking when giving me that book. I did read parts of it though, to my horror... I still have it around to remind me.).

So, if you're working with the security-related providers in ASP.NET 2.0 and don't have one - go get one now! (The Stefan Schackows book, not the JCL one).

Get a handle on controls

A common inconvenience is that in ASP.NET, controls that are part of templates are not directly accessible from code, frequently resulting in code like this:

TextBox myTextBox = wizardStep.FindControl("MyTextBox") as TextBox;
This has the added problem associated with the late binding of the control to an embedded text string ("MyTextBox"), a misspelling won't be discovered until the run-time hits this code. There's also no real assurance that it'll work as expected, since the the control found may in fact not even be a TextBox. Finally, FindControl() is not recursive, so you have to keep track of the exact correct container. All this is error prone and inconvenient.

It's been source of irritation for some time for me, and I've handled it in various ways in my code. Today I spent an hour doing this in a better way. Enter the ControlReference class, which looks like this:

public class ControlReference<T> where T : Control{ private EventHandler _eventHandler; public ControlReference(EventHandler eventHandler)
{
_eventHandler = eventHandler;
} public ControlReference() { } private T _control; public T Control
{ get { return _control; } set { _control = value; }
} public void OnInit(object sender, EventArgs e)
{
Control = (T)sender;
if (_eventHandler != null)
{
_eventHandler(sender, e);
}
}
}
(Formatting somewhat condensed for this format.)
When using this inside the template, you hook the OnInit event in the markup, like this:

<asp:TextBox runat="server" ID="MyTextBox" OnInit="myTextBox.OnInit" />
In the code, all you do is:

protected ControlReference<TextBox> myTextBox = new ControlReference<TextBox>();
...
myTextBox.Control.ForeColor = Color.Red;
This makes it easy, convenient and safe to refer to controls in templates