Sunday, July 08, 2007

Code Camp SA: Michael Baker

Michael Baker presented a session entitled "Design By Contract" on Saturday morning. Design by contract is a broad idea that can be approached in several ways. Michael focused on the idea of using pre- and post-condition macros in all your functions and combining that with extensive testing to ensure the conditions are met at runtime on all code paths. He also focused on implementing the macros as assertions rather than error return codes or exceptions.

I think that design by contract should not be treated so specifically but more as a combination of both discipline and an effective implementation for early problem detection.

You may establish a rule to document all methods with a comment header describing the intentions and expectations or you may insist (like FxCop) on throwing exceptions for invalid parameters. The important point is that it is done consistently.

As for effective implementation, comments are great for readability and guard clauses or unit tests are great for automated checking. However, the best outcome will be achieved with a system that can verify at compile time that all code paths pass the conditions and perhaps autogenerate human readable documentation too.

Defining the type of method parameters and return values in C# and VB is already a basic form of compile time verification of very basic conditions. Microsoft Research offers a variant of C#, known as Spec#. It extends on the C# language using new keywords and a variety of custom attributes to enable the developer to specify, declaratively, what values are valid as inputs and outputs from methods. The Spec# compiler is then able to use basic static analysis technique during build to highlight problem errors of code that could pass unacceptable values.

However, this all falls down when there are environmental conditions that cannot be verified at compile time. The absence of an expected file could throw an exceptions at runtime and the availability of network resources is a common problem also. Both Java and Spec# help here with checked exceptions and more advanced static analysis tools can track where possible exceptions can be thrown and verify that the application handles them appropriately.

Comments are closed.