I have been pretty excited about the technology behind Microsoft's Code Contracts for a while. However, as a user that typically is not situations where the Premium or Ultimate SKUs are affordable. With Visual Studio 2010, static code analysis was not included at the Professional level. For me, it is the static code analysis, not the run-time analysis that is where the value truly lies. As a long-time Microsoft developer I was pretty bummed about that. I sent an e-mail off to ScottGu about that and he gave a nice response and passed along my feedback. This is typical of the amazing support Microsoft has given the developer community over the years. I have been an Apple hardware user since the late 80s and have been very happy with Mac OS and iOS as a user. However, I don't think any of the major players, be the IBM, Oracle, Apple, treats developers as well as Microsoft does. If Windows 8 succeeds as a Tablet OS, which it should based on technical merit, the great Microsoft developer community will be part of that. Having said that, it is great to see Code Contracts coming to the masses with VS 2012 Pro. It is still a separate download for the analysis tools, although the actual Code Contract libraries are themselves baked into the .NET Framework.
As a footnote, I am not a fan of the strategy of the One OS To Rule Them All approach. I am not thrilled with my Windows 8 laptop setup. The UI between PC and tablet should be similar but fundamentally different. Unless my laptop has a touch screen, I want a keyboard/mouse centric UI with a conventional start menu. As a developer, I want to go further, and do as much as I can with a keyboard, without even having to reach to the mouse. Working in an office, I certainly can't use speech recognition either. It is important for Microsoft to allow business units that focus on different devices to innovate on their own. Long live skunkworks! After ScottGu's nice response, maybe I should pass these thoughts along to Steven Sinofsky as well ... Oh too late, nice knowing you Steven.
Showing posts with label Code Contracts. Show all posts
Showing posts with label Code Contracts. Show all posts
Friday, November 16, 2012
Thursday, June 16, 2011
Reflections on my Code Contracts experience
Microsoft has half-baked in Code Contracts to the .NET framework. Although having language-independent support for Code Contracts is a great step forward, widely available static analysis tools are the piece that makes contracts worthwhile. Until Code Contracts are available at the Visual Studio Professional level (it current requires the Academic or Premium versions) widespread adoption will not take hold.
I have been lucky enough to work with Visual Studio Ultimate so I’d like to share my experience of several months of working with contracts. This is based on my experience with release 1.4.31130.0 (November 30, 2010) which is not the current version (currently a Pi day release!). These tools are a community release, not a fully integrated final version so I won’t focus on the relatively few bugs or missing features.
I started with bringing up the adoption of contracts because of a beneficial snowball effect. Having an open source and commercial project use code libraries allows me to use, not abuse, their APIs. I think this is especially true for open source projects because developers like to write code, not documentation. Test driven development has been a boon for open source documentation, a benefit that doesn’t get the attention that other TDD benefits do. I can look at the tests to help understand how to use the code. The more documentation that can be incorporated as source code, the better developers who use a given library will be. Having contracts in place with static analysis can effortlessly (aside from slower compilation)push feedback to the developers, minimizing the effort developers need to take pull information based on reading code, comments, and documentation. Microsoft’s adoption of contracts within the .NET framework has already been helpful to me in preventing bugs. I am not talking about documentation in the conventional sense here, although I address that point below.
I have found it useful to switch between synchronous and asynchronous static analysis. If I really want to get the maximum benefits of contracts in an area I use synchronous analysis, where my build completes only after the static analysis is complete. However, the extra 5 to 10 seconds of compilation, in my development keeps me from keeping static remaining synchronous analysis be a permanent setting. I have to be in a coding area where I feel significant contracts benefits before I turn on synchronous static checking. This may seem like a small point to be focusing on one specific setting, but I feel usage patterns of synchronous analysis can be a great metric to see what a developer perceives as an ad hoc cost-benefit analysis of using contracts. I am sure many developers do have one consistent process and settings usage, and for those this wouldn’t be as good of a metric, but I am always a knob twiddler myself.
One way of classifying the development I do is between highly-reusable code and application code that I don’t find the cost-benefit of high reuse to be compelling. Code reuse is constantly cited benefit of OO programming but that benefit is often not significant enough to outweigh its cost. Reusable code often involves dealing with levels of abstraction that can make grokking using this reusable code take some time investment. My rate of line of code generation for reusable code is much, much lower. When you provide a library for others to use, you have to be prepared for every possible kind of abuse be made by callers. For less-reusable code, the level of paranoia in trusting the calling object can be reduced. In areas like null-checking this can be a tremendous use case for code contracts. I can assume that, for example a sequence of method calls that must occur in order, are being utilized by a developer more familiar with this codebase. They may still screw things up but my handling of mistakes can be simpler without trying to correct the misuse or going through significant effort to make clear exactly what the mistake was and how to rectify it. The sequence of methods calls is an example, though, of where contracts aren’t applicable, which I’ll expound upon below. Also, coming up with naming conventions and other forms of consistency is no mean task, as the very useful Framework Design Guidelines book illustrates.
Actual generated documentation can be another thing provided by Code Contracts, which is one of the bullets Microsoft has used as a selling point for contracts. I find the above split between highly reusable code and less reusable code to be applicable here to. I find this kind of documentation beneficial for highly reusable code, and less so otherwise. I feel the same way about XML documentation as used provided as input to tools like Sandcastle. When I am writing reusable code I try to write useful XML documentation but when I am not, I abhor writing code with it. I find it just clutters the code and too often I fall into the trap of not always writing comments that are truly meaningful. It can be too easy to rely on GhostDoc, wonderful tool that is, to provide documentation with zero value added. At the moment, the stable Sandcastle release doesn’t support processing code contract documentation. The Sandcastle project has a patch to support this, but I failed to get that working, and rolled back to the stable release.
Writing code that utilizes contracts leads one to a more functional approach, rather than an OO one. My experience with pre and post conditions was more immediately fruitful than my use of object invariants. When I focused on not having side effects and not storing state in objects, that is the scenario where pre and post conditions are valid. Any possibility of side effects limits or eliminates the applicability of this variety of contracts. In my example earlier in this post, a scenario where I relied on a sequence of method calls being made relies on object state to work, and is beyond the scope of where contracts can help, at least today’s version of contracts. In the much smaller time I have played with object invariants, I didn’t get static analysis findings that I had hoped for. It is quite possible that this just requires more effort on my part to obtain benefit there. Interestingly, although I see contracts being awesome for functional programming, it seems like the current state of f# support may be lacking as this blog post suggests.
I have found myself deciding what classes go in what assemblies partly based on whether I am using contracts. Code contracts can provide a lot of data to either treat as warnings or errors. Employing implicit non null checking for example, means that calling code will need to do a LOT of error handling. In a less reusable scenario, it can be convenient to have null checking done by the called code in one place, rather than in each piece of calling code. In such a scenario, I would still check for contract usage based on other assemblies, I would just not create contracts for the classes within this assembly.
To get serious with Code Contract usage requires dealing with a large volume of warnings. Unless you are in a situation where 100% compliance is pursued, there will be warnings that you’d like to disregard. Code Contracts attempts to deal with this through using baseline files. These represent a list of warnings previously observed to be disregarded. I didn’t spent much time trying to use this feature but when I tried I couldn’t get it to work. Another option available is using the ContractVerification attribute to allow classes, methods, or even assemblies to selectively be ignored or verified.
Code Contracts is a really compelling feature. At this time, provided my employer has the license for static analysis, I will continue to use Code Contracts for high reuse code. Since I only have professional at home, my side projects will go without Code Contracts. Until Microsoft decides when and how to fully include Code Contract support within Visual Studio, I am leery of an “all-in” Code Contract usage for a team.
I have been lucky enough to work with Visual Studio Ultimate so I’d like to share my experience of several months of working with contracts. This is based on my experience with release 1.4.31130.0 (November 30, 2010) which is not the current version (currently a Pi day release!). These tools are a community release, not a fully integrated final version so I won’t focus on the relatively few bugs or missing features.
I started with bringing up the adoption of contracts because of a beneficial snowball effect. Having an open source and commercial project use code libraries allows me to use, not abuse, their APIs. I think this is especially true for open source projects because developers like to write code, not documentation. Test driven development has been a boon for open source documentation, a benefit that doesn’t get the attention that other TDD benefits do. I can look at the tests to help understand how to use the code. The more documentation that can be incorporated as source code, the better developers who use a given library will be. Having contracts in place with static analysis can effortlessly (aside from slower compilation)push feedback to the developers, minimizing the effort developers need to take pull information based on reading code, comments, and documentation. Microsoft’s adoption of contracts within the .NET framework has already been helpful to me in preventing bugs. I am not talking about documentation in the conventional sense here, although I address that point below.
I have found it useful to switch between synchronous and asynchronous static analysis. If I really want to get the maximum benefits of contracts in an area I use synchronous analysis, where my build completes only after the static analysis is complete. However, the extra 5 to 10 seconds of compilation, in my development keeps me from keeping static remaining synchronous analysis be a permanent setting. I have to be in a coding area where I feel significant contracts benefits before I turn on synchronous static checking. This may seem like a small point to be focusing on one specific setting, but I feel usage patterns of synchronous analysis can be a great metric to see what a developer perceives as an ad hoc cost-benefit analysis of using contracts. I am sure many developers do have one consistent process and settings usage, and for those this wouldn’t be as good of a metric, but I am always a knob twiddler myself.
One way of classifying the development I do is between highly-reusable code and application code that I don’t find the cost-benefit of high reuse to be compelling. Code reuse is constantly cited benefit of OO programming but that benefit is often not significant enough to outweigh its cost. Reusable code often involves dealing with levels of abstraction that can make grokking using this reusable code take some time investment. My rate of line of code generation for reusable code is much, much lower. When you provide a library for others to use, you have to be prepared for every possible kind of abuse be made by callers. For less-reusable code, the level of paranoia in trusting the calling object can be reduced. In areas like null-checking this can be a tremendous use case for code contracts. I can assume that, for example a sequence of method calls that must occur in order, are being utilized by a developer more familiar with this codebase. They may still screw things up but my handling of mistakes can be simpler without trying to correct the misuse or going through significant effort to make clear exactly what the mistake was and how to rectify it. The sequence of methods calls is an example, though, of where contracts aren’t applicable, which I’ll expound upon below. Also, coming up with naming conventions and other forms of consistency is no mean task, as the very useful Framework Design Guidelines book illustrates.
Actual generated documentation can be another thing provided by Code Contracts, which is one of the bullets Microsoft has used as a selling point for contracts. I find the above split between highly reusable code and less reusable code to be applicable here to. I find this kind of documentation beneficial for highly reusable code, and less so otherwise. I feel the same way about XML documentation as used provided as input to tools like Sandcastle. When I am writing reusable code I try to write useful XML documentation but when I am not, I abhor writing code with it. I find it just clutters the code and too often I fall into the trap of not always writing comments that are truly meaningful. It can be too easy to rely on GhostDoc, wonderful tool that is, to provide documentation with zero value added. At the moment, the stable Sandcastle release doesn’t support processing code contract documentation. The Sandcastle project has a patch to support this, but I failed to get that working, and rolled back to the stable release.
Writing code that utilizes contracts leads one to a more functional approach, rather than an OO one. My experience with pre and post conditions was more immediately fruitful than my use of object invariants. When I focused on not having side effects and not storing state in objects, that is the scenario where pre and post conditions are valid. Any possibility of side effects limits or eliminates the applicability of this variety of contracts. In my example earlier in this post, a scenario where I relied on a sequence of method calls being made relies on object state to work, and is beyond the scope of where contracts can help, at least today’s version of contracts. In the much smaller time I have played with object invariants, I didn’t get static analysis findings that I had hoped for. It is quite possible that this just requires more effort on my part to obtain benefit there. Interestingly, although I see contracts being awesome for functional programming, it seems like the current state of f# support may be lacking as this blog post suggests.
I have found myself deciding what classes go in what assemblies partly based on whether I am using contracts. Code contracts can provide a lot of data to either treat as warnings or errors. Employing implicit non null checking for example, means that calling code will need to do a LOT of error handling. In a less reusable scenario, it can be convenient to have null checking done by the called code in one place, rather than in each piece of calling code. In such a scenario, I would still check for contract usage based on other assemblies, I would just not create contracts for the classes within this assembly.
To get serious with Code Contract usage requires dealing with a large volume of warnings. Unless you are in a situation where 100% compliance is pursued, there will be warnings that you’d like to disregard. Code Contracts attempts to deal with this through using baseline files. These represent a list of warnings previously observed to be disregarded. I didn’t spent much time trying to use this feature but when I tried I couldn’t get it to work. Another option available is using the ContractVerification attribute to allow classes, methods, or even assemblies to selectively be ignored or verified.
Code Contracts is a really compelling feature. At this time, provided my employer has the license for static analysis, I will continue to use Code Contracts for high reuse code. Since I only have professional at home, my side projects will go without Code Contracts. Until Microsoft decides when and how to fully include Code Contract support within Visual Studio, I am leery of an “all-in” Code Contract usage for a team.
Friday, September 10, 2010
A few links pertaining to my code contracts talk
I am giving an intro talk on Code Contracts tomorrow for the Central PA .NET Code Camp 2010.
Here a few links from that talk.
Here a few links from that talk.
- Code Contracts web site
- Sample chapter on Code Contracts from Jon Skeet's book C# in Depth (second edition)
- Pex for Fun web site that I took examples from.
- Excellent series of blog posts from Kevin Hazzard on code contracts
Code Contracts Support within .NET Framework BCL
Code Contracts were one of the Holy Grails in Computer Science when I received my bachelor’s degree in 1997. Yes, there was research aplenty including my professor Dr. Tim Wahls’ work with the Larch and later Java Modeling Language (JML) approaches to Design By Contracts. However, it was far removed from mainstream programming. Microsoft is poised to change that with Code Contracts.
Code Contracts allow formal specifications to be applied to code. These consist of preconditions, post-conditions, and object invariants. The idea is that code can have its intent made clearer for callers by specifying characteristics of valid use and code that calls code with contracts available can be more reliable by guaranteeing that the contracts aren’t broken. Compile-time checking allows abuse of contracts to be caught very early in the development cycle. An excellent chapter by Jon Skeet from C# in Depth (second edition) covering contracts is available here.
Code Contracts are still a development labs product but Microsoft has already modified some BCL code to support contracts. An earlier draft of Skeet’s chapter illustrates the progress is making. An example showing a case beyond what Code Contracts were NOT aware of is now caught by .NET 4 and the static contract checker! The system random number generator Next function takes two arguments , a lower bound and upper bound, and produces a pseudorandom number >= lower bound and < upper bound. Looking at the BCL source available through Microsoft’s symbol server shows a contract that stipulates that the lower bound can’t be larger than the upper bound.
int randomNum;
Random randomGenerator = new Random();
randomNum = randomGenerator.Next(7, 1);
//caught as an exception violation
If we have a function with a precondition that an input number is a valid output of a six-sided die, then the static contract checker uses the contracts built-in to the BCL to support its inference. The static check has found that the output of the Next function will always produce legal input.
Random randomGenerator = new Random();
randomNum = randomGenerator.Next(1, 7);
Subscribe to:
Posts (Atom)