Oder: Würdet Ihr auf Geschenke, die das Leben vereinfachen, verzichten?

Viele werden schon davon gehört haben, und viele werden es auch schon kennen: Code Contracts. Obwohl Code Contracts noch nicht offiziell veröffentlicht wurden, sind Code Contracts mittlerweile keine neue Sache. Im Gegenteil, Durch die massive, jahrelange Forschungsarbeit von Microsoft sind Code Contracts seit über einem Jahr sehr stabil und zuverlässig. Interessanterweise wurden Code Contracts nicht spezifisch erforscht, sondern sind als “Nebenprodukt” der Forschungen zu Boogie/Clousot (der statischen Verifikationskomponente von Spec#) entstanden.

Man findet mittlerweile sehr viele Beispiele und Casts zu Code Contracts und all den Features, die Code Contracts mit sich bringen. Ein aktuelles Video und eine wirklich sehenswerte, einfache Einführung in die Features ist die PDC09 Session über Code Contracts und PEX (dem automatisierten Unit Testing Tool). Es ist konsequenterweise nicht verwunderlich, dass Code Contracts seit über einem halben Jahr in den DevLabs zur Verfügung gestellt werden und mit .NET 4.0 in der mscorlib integriert sein werden (also in .NET 4.0 mit enthalten sein werden).

Parameterverifikation mit Stil

Eine besondere und herausstechende Eigenschaft der Code Contracts ist jedoch, dass es sich wunderbar einfach in eine existierende Code-Basis einführen lässt. Dadurch das Code Contracts viele Vorteile mit sich bringen, kann man eine stufenweise Integration anstreben. So ist es eine gangbare Methode, Code Contracts im ersten Schritt für die Dinge einzusetzen, die man sowieso schon jahrelang macht, wie z.B. Parameterprüfungen in Methoden (Vorbedingungen):

//...
public void ProcessOrder(IOrder order)
{
  if (order == null) throw new ArgumentNullException();
  //...
}
//...

Diese “Contracts” werden mittlerweile von Tools wie ReSharper oder CodeRush auf Wunsch automatisch generiert, um dem Entwickler den Tippaufwand zu ersparen. Es gibt in manchenvielen Anwendungen und API’s auch nette Hilfsklassen, die diese Prüfungen beschleunigen:

//...
public void ProcessOrder(IOrder order)
{
  Argument.MayNotBeNull(order);
  //...
}

public static class Argument
{
  public static void MayNotBeNull(object o)
  {
    if (o == null) throw new ArgumentNullException();
  }
}

Genau dieser, ich möchte schon fast sagen tagtägliche Anwendungsfall kann mit Code Contracts sofort umgesetzt werden:

public void ProcessOrder(IOrder order)
{
  Contract.Requires(order != null);
  //...
}

Lesbar, einfach und effektiv gesehen exakt das selbe, was man schon seit Jahren “per Hand” programmiert. Das Schöne ist hier allerdings, das es die Tür für die weiteren Tools (z.B. statische Verifikationsanalyse) öffnet. Mit der Zeit kann man auch nicht nur die Preconditions mit den Code Contracts umsetzen, sondern auch die Postconditions und Invariants einsetzen.

In einem späteren Schritt kann man zu den Prüfungen zur Laufzeit auch die statische Verifikation noch mit einführen, um kritische Anwendungsteile in der Stabilität zu stärken. Es gibt noch viele weitere Vorteile, die Code Contracts mit sich bringen (z.B. Verifikationsdefinitionen auf Schnittstellen), auf die ich hier nicht näher eingehen werde. Ich denke jedoch, dass jeder, der sich ein wenig mit den Code Contracts auseinandersetzt, die klaren Vorteile erkennen wird.

Weihnachten ohne Geschenke?

Die Frage ist nun: würde man Code Contracts in eine bestehende heute schon Codebasis integrieren wollen? Die aktuelle Version der Code Contracts muss man separat referenzieren, denn die Contracts werden erst mit .NET 4.0 ein fester Bestandteil der BCL sein. Man stelle sich nun ein agiles Projekt vor, in dem wöchtenliche Releases keine Seltenheit sind. Würde man in so einer Situation den Einsatz von Code Contracts befürworten oder eher abwarten, bis es .NET 4.0 veröffentlicht wurde. Lizenzteichnisch gäbe es keine Probleme, zumal die Code Contracts in der aktuellen Version schon über eine Going-Live-Lizenz verfügen.

Dafür spricht, dass die Code Contract API schon seit über einem Jahr stabil ist. Die Contract-Assembly wurde sehr sorgfältig über einige Jahre hinweg entwickelt. Ein weiteres Pro-Argument ist sicherlich die definitive Integration mit .NET 4.0. Schon heute steht fest, dass System.Diagnostics.Contracts eine fester Bestandteil der neuen .NET-Version sein wird. Die Vorteile, die die Code Contracts selbst mit sich bringen (also verbesserte Verifikation zur Laufzeit, statische Verifikation, erleichterter Einsatz von weiterführenden Tools wie z.B. PEX) erwähne ich nur nebenbei.

Dagegen würde wohl momentan nur die Tatsache sprechen, dass die Contracts noch nicht Final sind. Die API kann sich in den einigen Monaten bis zur Veröffentlichung von .NET 4.0 noch ändern (obwohl es lt. Aussage der Entwicklungsmannschaft wohl unwahrscheinlich ist). Ein weiteres Gegenargument für den sofortigen Einsatz ist wohl das Deployment. Abhängig vom Anwendungstyp muss man da einige Parameter berücksichtigen. Doch für den jetzigen Anwendungsfall möge man von einem agilen Software-Projekt mit frequentiven Releases ausgehen, z.B. ganz klassisch bei einer Web-Anwendung. Hier muss man abwägen, ob man die Contracts-Assembly auf den Webservern im GAC installiert oder mit den eigenen Assemblies mit ausliefert.

Nach dieser kurzen Pro-Contra-Gegenüberstellung würde mich Eure Meinung interessieren. Was meint Ihr? Wer setzt es heute schon ein? Wer möchte es noch vor dem .NET 4.0 Release einsetzen? Wer möchte lieber abwarten bis .NET 4.0?

Die Frage ist: Das Geschenk “Code Contracts” heute schon annehmen und einsetzen? Ja oder Nein?