Brennan’s Blog

We have more options these days for creating robust applications. Back when I wrote a lot of code in Perl I wrote very defensive code. Each subroutine would verify assumptions about incoming parameters and correct problems whenever possible. And I found that it saved me some headaches because later the code had been changed, and while the change introduced a bug, the code continued to work in the Production environment. It was all due to the defensive strategy.

The brittle code strategy is another concept I have used. Essentially, if something is broken I want it to break. And I want it to break universally.

A common point where I always insert brittle code is the startup of an ASP.NET application. You can handle the Application_Start event and validate the configuration for the runtime. If you have settings to define locations of folders which are necessary to the proper running of the website, I simply throw an exception to state that fact. I call this a sanity check. And whenever the application is deployed I know immediately if the application will run properly, because if it was going to break, it would break universally.

Now that we have testing frameworks, which are more mature each year, we can put less effort into the defensive coding strategy because the tests will catch it, right? Well, I think it comes down to how mature your testing framework allows you to get and how complete your test suite checks your application. Assuming you do have a powerful testing framework with a comprehensive test suite you can start writing brittle code which will break when a developer introduces code which does not follow the rules. And a comprehensive test suite will throw some garbage at the system to verify that it handles the garbage properly.

Should I now abandon defensive coding and just trust in the test framework to validate my brittle code? I am not ready for that. I think a hybrid approach should be applied where you do not fully give up on the defensive strategy but still maintain strong object encapsulation. And then wrap a healthy amount of tests around your encapsulated objects to ensure strict conformance to your requirements.

As a part of that encapsulation, modern testing frameworks can evaluate the complexity of your code. If a single method is over 300 lines long and has 25 control statements (if, for, while), it should be simplified by breaking that method into smaller methods with specific tasks. (see Cyclomatic Complexity) Code analysis is different than brittle or defensive code, but does fall back on relying on the testing framework which allows you to lean in the direction of brittle code. The code complexity analysis is now more than just an indicator of whether or not the build was successful, but also a guide for your architectural decisions.

When Extreme Programming and Agile Methodologies became hot just a few years back I felt that unit tests were great, but also lacking. Now it seems the available frameworks are quite rich. And when they are used properly, they should dramatically improve the quality of the applications we deliver.