Now that I have the time for it, I’m going through a lot of material I’ve been collecting in my To Read folder over the past year or so. One of the videos I watched is Mike Barnett’s talk about Spec# at the recent Lang.NET Symposium.
What Spec# does, in a few words, is to add contracts to your code: Your method never returns null? Set this as a contract and everyone calling your method could rely on this; Should you always receive a number between x and y into a certain parameter? Set this as a contract and no one can call your method before their code explictly shows that the parameter is between those boundries.
Except for the fact that it shows some awesome concepts in keeping everything nice, clean and also reduces the amount of unit testing required by using these contracts, it made me say “woah, I didn’t even think of that,” when the squiggly lines started appearing in places I hadn’t expected (yes, it works in the background and shows you problems as you code). However, I can’t seem to stop thinking that Spec# has one huge fault: Out of all of the developers I have ever worked with, about 90% will never use it unless they are forced too, which is sad. I feel this is going the way of checked exceptions in Java, where the functionality is there and is great when used, but most people just don’t use it because it’s less work and the code still works.
I, for one, would love to see Spec# embedded into C# 4.0 (my guess is it won’t be ready for 3.0), after the syntax is cleaned up a bit. I think it’s a great and welcome step forward in code-hardening, but its biggest problem is how to make Spec# such an integral part of C# so that it doesn’t follow the footsteps of other great software features no one ever uses.