{"id":303,"date":"2009-03-15T10:46:27","date_gmt":"2009-03-15T09:46:27","guid":{"rendered":"http:\/\/www.leading-edge-dev.de\/?p=303"},"modified":"2010-07-10T16:21:17","modified_gmt":"2010-07-10T15:21:17","slug":"code-contracts-code-transformation","status":"publish","type":"post","link":"https:\/\/www.minddriven.de\/index.php\/technology\/dot-net\/code-contracts-code-transformation","title":{"rendered":"Code Contracts #2: Code transformation"},"content":{"rendered":"

In my first blog post<\/a> about Code Contracts, I covered the origins of the project and the elementary pieces of programming by the DbC principle: pre-conditions, post-conditions and invariants. Now let’s dig a little deeper and look at more background information about how contracts on your code are evaluated…<\/p>\n

At first, let’s look again at the example of the Deposit<\/code>-method from the last blog post:<\/p>\n

public void Deposit(int amount)\r\n{\r\n    Contract.Requires(amount > 0);\r\n    Contract.Ensures(Balance == Contract.OldValue(Balance) + amount);\r\n\r\n    Balance += amount;\r\n}<\/pre>\n
As you can see, contracts on methods (pre- and post-conditions) are defined imperatively<\/em> inside the method. But instead of this definition, in fact their behavior is declarative<\/em>! Thus they are not called at runtime as it is expected through the imperative style. If you debug the method and set a breakpoint on the contract’s position, then the debugger will not break there. In truth there is a component of Code Contracts called Code Rewriter<\/strong> (ccrewrite), which is performing a post-compile<\/em> process on the IL-code, that’s generated by the compiler. Thus, every Code Contracs definition is set to its correct<\/em> location in the IL code. For example, pre-conditions are set to the beginning of a method, post-conditions to the end, just before the (every) method exit, regardless to the location, where they have been defined imperatively. A look through the .NET Reflector<\/a> googles over the created assembly makes this clear, too. The reflected code of the Deposit<\/code>-method looks as follows:<\/p>\n
public void Deposit(int amount)\r\n{\r\n    __ContractsRuntime.Requires(amount > 0, null, \"amount > 0\");\r\n    int Contract.Old(Balance) = this.Balance;\r\n    \r\n    this.Balance += amount;\r\n\r\n    __ContractsRuntime.Ensures(this.Balance == (Contract.Old(Balance)\r\n        + amount), null, \"Balance == Contract.OldValue(Balance) + amount\");\r\n}<\/pre>\n
As expected, the pre-condition is evaluated at the beginning, the post-condition at the end of the method. Moreover, at the beginning of the method (after the pre-condition has been evaluated) the old value of Balance<\/code> is stored into a temporary variable, thus enabling Ensures()<\/code> to have access on it.<\/p>\n
With the existing example of the Deposit<\/code>-method, there are some questions that come into the programmer’s mind. For example, why are Code Contracts defined (not very intuitively) imperatively inside a method and not as attributes<\/strong><\/em> for the method as one would expect through their declarative nature, thus leading to code pollution? The answer is, that attributes are too limited in their expressiveness. To allow full flexibility, conditions would have to be declared as string<\/code> and you would have no IDE-support (Intellisense, compiler support) any more. Furthermore, the strings would have to be parsed by Code Contracts, what’s error prone at all. If attributes in .NET (C#, VB, …) would be more expressive and allow more aspect oriented programming (AOP) features, then it would be possible to define contracts via attributation, but not until now. Ok, when not using attributes, why aren’t there additional keywords<\/strong><\/em> for definition of Code Contracts as in Spec#? For example, why aren’t there requires<\/code> and ensures<\/code> keywords that are defined between method head and body and thus making the sense much more clearer and separating contracts from core logic? Please have in mind, that keywords are language-based features! Instead, the Code Contracts library becomes an element of the .NET 4.0 CLR and thereby it covers all<\/em> .NET based languages, from which it can be used consequently. It would be nice to have such keywords, but it’s not the task of the Code Contracts developer team, but of the C# (and other .NET languages) team. Perhaps we’ll see such keywords in C# 5.0? Who knows…<\/p>\n
That’s it again for the moment. In this blog post I covered the topic of code transformation by the Code Rewriter a little bit and made some statements about the declarative nature of Code Contracts. In upcoming blog posts, I want to show you the evaluation elements (checkers) of Code Contracts and give more examples, how contracts on various code elements can be defined…<\/p>\n
\"kick<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
In my first blog post about Code Contracts, I covered the origins of the project and the elementary pieces of programming by the DbC principle: pre-conditions, post-conditions and invariants. Now let’s dig a little deeper and look at more background information about how contracts on your code are evaluated… At first, let’s look again at … Code Contracts #2: Code transformation<\/span> weiterlesen<\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6,126],"tags":[140,319,138,139,141,137,136],"class_list":["post-303","post","type-post","status-publish","format-standard","hentry","category-dot-net","category-code-contracts","tag-attributes","tag-code-contracts","tag-code-rewriter","tag-code-transformation","tag-keywords","tag-post-conditions","tag-pre-conditions"],"_links":{"self":[{"href":"https:\/\/www.minddriven.de\/index.php\/wp-json\/wp\/v2\/posts\/303","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.minddriven.de\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.minddriven.de\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.minddriven.de\/index.php\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.minddriven.de\/index.php\/wp-json\/wp\/v2\/comments?post=303"}],"version-history":[{"count":11,"href":"https:\/\/www.minddriven.de\/index.php\/wp-json\/wp\/v2\/posts\/303\/revisions"}],"predecessor-version":[{"id":958,"href":"https:\/\/www.minddriven.de\/index.php\/wp-json\/wp\/v2\/posts\/303\/revisions\/958"}],"wp:attachment":[{"href":"https:\/\/www.minddriven.de\/index.php\/wp-json\/wp\/v2\/media?parent=303"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.minddriven.de\/index.php\/wp-json\/wp\/v2\/categories?post=303"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.minddriven.de\/index.php\/wp-json\/wp\/v2\/tags?post=303"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}