About DbC, pros & cons

[Brad Roberts]

On Thu, 30 Sep 2010, bearophile wrote:

> A small article about design by contracts in C# dotnet 4. The comments 
> after the article show some interesting critique to the DbC that look 
> more interesting than the article itself:
> 
> http://www.infoq.com/news/2008/11/Code-Contracts
> 
> That critique is right, but wrong too. Contracts are a kind of type 
> system. They put limits and add rigidity between the interfaces (not 
> meant in their D language meaning) between code subunits. Dynamic type 
> systems allow faster updates when parts change, while strict type 
> systems, unittests and Dbc increase your confidence that the code does 
> what you want and reduce unwanted interactions between subsistems of 
> your program, and at the same time they introduce long-distance coupling 
> among those subsystems. So in the end life is about trade-offs. Even 
> unittests may add such rigidity that has a cost.
> 
> If you have to write code that guides the Space Shuttle you want it to 
> be perfect, and you want to use DbC enforced statically, while if you 
> want to write software that deals with ever mutating commercial 
> realities, you prefer something like C# or Python that allows you to 
> change your code with less work.
> 
> D looks designed more for numerical code, where rules don't change or 
> change slowly, and less fit for commercial code that needs to be changed 
> often.

I disagree with this logic.  The additional checking you can do with 
contracts makes it easier to make changes with confidence about catching 
unwanted side effects.  That both raises your confidence and reduces the 
time spent studying code to find unwanted side effects or debugging 
because you missed them.  They're found quickly.

The general theory that the earlier you find a bug the cheaper it is to 
fix it applies quite well here.

Later,
Brad