Cloud Foundry: Design and Architecture
Derek Collison discusses the goals, the design premises and patterns employed in creating the architecture of Cloud Foundry, VMware’s open source PaaS, unveiling internal architectural details.
News
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Code Contracts are Making Slow Progress
Posted by Jonathan Allen on Dec 02, 2009
Code Contracts are making slow progress towards being ready for production use. While the technology still shows a lot of initial promise, it doesn’t take long to run into a road block or six that makes them unusable in their current form.
One of the most basic and important features of Code Contracts is null reference detection. The ability to detect possible null reference exceptions at compile time would be a huge win for developers. Unfortunately Code Contracts just doesn’t work when it comes to this.
The biggest offender is the inability to understand the readonly modifier on fields. Developers have been using this in C# and VB since .NET 1.0 to indicate that a field can never be changed outside its constructor. Often it is paired with an in-line initializer, making it verifiably clear the field can never be null. Unfortunately the static checker in Code Contracts doesn’t honor the readonly modifier nor does examine the assignments for the field, causing a lot of false warnings.
A big issue for Visual Basic developers is that the static checker doesn’t understand the “If (aString = "")” syntax. Being semantically identical to relatively new “String.IsNullOrEmpty” function, idiomatic VB code uses this for most null string checks. Since the static checker effectively ignores any line that looks like that, VB developers are plagued with lots of additional false warnings. According to Francesco Logozzo of Microsoft, this is finally being addressed in the next release.
Another problem for which no visible progress is being made is the lack of attributes for common scenarios. For example, most functions that return objects will want to ensure the result is not null. This requires this rather tedious code.
Contract.Ensures(Contract.Result(OfSomeType)() IsNot Nothing)
Contract.Ensures(Contract.Result<SomeType>() !=null);
What developers have been asking for is a simple attribute.
<NotNull()>PublicFunctionFoo() As SomeType
[NotNull] SomeType Foo()
Since Code Contracts includes an assembly rewriter, adding attributes that translate into other common scenarios like whether or not a given parameter accepts nulls should be easy. It could even automatically generate the correct code to throw an ArgumentNull or ArgumentOutOfRange exception.
Unfortunately the Code Contracts team has, from the beginning, been antagonistic towards code bases that need to support clients that don’t use Code Contracts. For example, they want to use assertions instead of exceptions for errors that would normally throw ArguementException. This, of course, is totally unacceptable as a failed assertion would automatically crash the entire program without chance for recovery.
Since then the situation has gotten worse rather than better. Turning on runtime checking will actually disable the argument checks written in the “If check Then Throw” style.
A down-right daunting problem facing the Code Contracts team is the sheer size of the .NET framework. In addition to solving some serious issues with both the static checker and the way they deal with non-Code Contract code bases, they have to go back and define the contracts for countless classes. So far even the basic contracts like “For all ICollection<T>, calling Add will increment Count by 1.” are not currently working correctly.
It should be noted that none of these problems can’t be overcome given sufficient time and resources. Code Contracts still remain a very promising technology that over time can greatly reduce or even eliminate whole classes of errors for those with the time and patience to learn these powerful but complicated tools.
RelatedVendorContent
Automating Error Reporting for .NET Applications
Visual Studio vNext: ALM features for Agile Planning, Team Collaboration
Troubleshoot Java/.NET performance while getting full visibility in production
Combining Inspections, Static Analysis, Testing to Achieve >95% Defect Removal Efficiency
Related Sponsor
In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!
Progress
by
Bruce Robertson
Posted
Re: Progress
by
Jonathan Allen
Posted
Version?
by
Cheng Michael
Posted
Re: Version?
by
Jonathan Allen
Posted
Re: Version?
by
Ryan Riley
Posted
good-for-nothing critics
by
Kostya K
Posted
ValidationAspects
by
Gennadii Donchyts
Posted
-
Not making slow progress? So they ARE making fast progress?
-
What version you talked about?
-
Sorry about that. Originally it said "Code Contracts are not making any progress", but I let the article sit for a few days to get feedback on some of the more egregious bug reports. Most of the bugs, especially the thing about readonly fields and VB strings, have been lingering for well over half a year. I had to tone it down a bit once they finally said they are going to fix the string bug, as it shows they are at least moving forward.
I have to say I hated writing this piece. I wanted it to be a showcase for how well they were doing, but even my utility library the number of false positives was staggering. I spent the better part of two weeks refining my code so it would play nicely with the new FxCop and Code Contract builds, but I just couldn’t make meaningful headway. -
I installed the VSTS version from the link in the article in late November. Based on what I've been reading in the forums I believe that the next build is going to have significant improvements when it comes to functionality.
As for the syntax, I don't see them changing to a declarative, attribute-based style any time soon. This is sad because there are wish lists dating back to .NET 1.0 with requests for <NotNull> and <Range(min, max)> attributes. Perhaps when "compiler as a service" comes online somewhere around .NET 5 or 6 we can just build it ourselves and emit the correct Contract.Requires code. -
Declarative attributes already exist in the form of DataAnnotations, which are also getting a face lift in .NET 4.0. You could also get a similar effect with the Validation block from the Enterprise Library. I wonder if you understand the intent of Code Contracts. You noted the "if check else throw" style, and those are much closer to what these do for you. I quite like what the Code Contracts team has done, in particular in the use of interfaces for defining contracts to keep the actual class clean.
-
Code Contracts is an amazing new tool, whatever problems it still has, it's a big step forward developers should be grateful for. The Code Contracts' team did a good job.
-
ValidationAspects seems to do the many things similar to Code Contracts but the code looks much cleaner: validationaspects.codeplex.com/.
7 comments
Watch Thread Reply