Using Code Contracts

[manu-st]

I know there was a conscious decision not to use Code Contracts based on the discussion that was happening on the CoreFX repository (https://github.com/dotnet/corefx/issues/503).

However, here in CoreRT, I think everyone working on it would benefit from Code Contracts, not just for getting failures at runtime when something goes wrong, but for readers to better understand how things are supposed to work without having to dig too deep in the actual implementation. The later is what I feel is most important.

For example,

 public CachingMetadataStringDecoder(int size) : base(System.Text.Encoding.UTF8)
        {
            // Verify that the size is power of 2
            Debug.Assert((size & (size - 1)) == 0);
            _table = new Entry[size];
        }

would be better formulated into

 public CachingMetadataStringDecoder(int size) : base (System.Text.Encoding.UTF8)
        {
            Contract.Requires((size & (size - 1)) == 0, "Argument size must be a power of two");
            _table = new Entry[size];
        }

and combined with IntelliSense you do not have to dig into the implementation of this member to figure this out.

The other benefit of using Code Contract is to distinguish between Requires, Assert and Ensures, when currently you can only express one variant: Debug.Assert.

[stephentoub]

For example

To be a fair comparison, your Debug.Assert should also contain the explanation message.

combined with IntelliSense

There is such value in code contracts, but only when the code contracts tooling is employed as part of the build. Otherwise, I'd argue there's actually decreased value in code contracts, because many of the Contracts that get written aren't compiled in.

[manu-st]

Indeed but this example was taken verbatim from the current source code.

As for the tooling, the only good thing is that if you do not install Code Contracts the code still compiles (so this is not a show stopper) but I agree that if you do not install Code Contracts it is as good as putting comments.

[stephentoub]

Indeed but this example was taken verbatim from the current source code.

Understood. I was just pointing out that if part of the goal is to document what the assert/requires is checking for, that can be done without making the leap to code contracts.

[jkotas]

everyone working on it would benefit from Code Contracts

Code contracts have benefits, but they also do have costs. We have been experimenting with code contracts for years. We have found that the costs outweigh the benefits in the current implementation.

This equation has to change first in order for them to be viable, e.g. building them as first class language construct dotnet/roslyn#119

[manu-st]

My understanding was that they put some burden on the compilation steps because of the rewrite step and I've also encountered issues with the rewriting. The run-time cost should be very similar though when there is no violation. Can you shed some light on the other costs?

Can we standardize some practice to replicate the assert into the XML documentation of members while waiting for contracts to be first class language construct?

[MichalStrehovsky]

Closing based on the discussion.