Quel est le degré de maturité du cadre Microsoft Code Contracts ?

Question

Microsoft a récemment mis en place une version de son Contrats de code sur DevLabs avec une licence commerciale. Nous souhaitons les utiliser dans notre projet (principalement C#, un peu C++/CLI) pour remplacer progressivement tout le code de validation personnalisé, mais j'aimerais connaître l'expérience d'autres personnes avant de nous engager :

• Pensez-vous que le cadre est suffisamment mature pour des projets commerciaux importants et complexes ?

• Quels sont les problèmes que vous avez rencontrés en l'utilisant ?

• Quels avantages en avez-vous tirés ?

• Est-il actuellement plus douloureux qu'il ne vaut la peine ?

Je me rends compte qu'il s'agit d'une question quelque peu subjective car elle requiert une opinion, mais étant donné que ce cadre est une partie très importante de .NET 4.0 et qu'il va (potentiellement) changer la façon dont nous écrivons tous du code de validation, j'espère que cette question sera laissée ouverte pour recueillir l'expérience sur le sujet afin de m'aider à prendre une décision sur une question spécifique à laquelle il est possible de répondre :

Devrions-nous commencer à l'utiliser le mois prochain ?

Notez que nous ne fournissons pas d'API de code, mais uniquement un service web, donc pour la majorité du code, la compatibilité en termes de type d'exception déclenchée n'est pas un problème. Cependant, comme j'espère que d'autres personnes que moi tireront profit de cet article et de ses réponses, tout détail dans ce domaine est le bienvenu.

Answer 1

La dernière réponse mature à ce sujet remonte à 2009, et .NET 4 est sorti. Je pense qu'une mise à jour s'impose :

Les contrats de code pourraient bien être assez matures pour vos versions de débogage.

Je réalise que c'est une sorte d'amélioration de "inoffensif" à "presque inoffensif".

El Page d'accueil des contrats de code liens vers une documentation assez complète au format PDF. La documentation décrit les directives d'utilisation dans la section 5. Pour résumer, vous pouvez choisir à quel point vous vous sentez courageux sur les outils de contrat qui réécrivent votre IL dans vos constructions de version.

Nous utilisons le mode "ne réécris pas mon IL de libération".

Jusqu'à présent, j'apprécie surtout cet avantage inattendu : il y a moins de code, donc moins de code à tester . Toutes vos clauses de sauvegarde disparaissent.

if(arg != null) { 
    throw new ArgumentNullException("arg"); 
}
// Blank line here insisted upon by StyleCop

devient :

Contract.Requires(arg != null);

Vos fonctions sont plus courtes. Votre intention est plus claire. Et vous n'avez plus besoin d'écrire un test nommé ArgumentShouldNotBeNull pour atteindre une couverture de 100 %.

Jusqu'à présent, j'ai rencontré deux problèmes :

• J'avais un test unitaire qui dépendait de l'échec d'un contrat pour réussir. Vous pourriez dire que l'existence de ce test était une erreur, mais je voulais documenter cette interdiction particulière sous la forme d'un test. Le test a échoué sur mon serveur de compilation parce que je n'avais pas installé les outils. Solution : installez les outils.

• Nous utilisons deux outils qui réécrivent l'IL : Contrats de code y PostSharp . Ils ne s'entendaient pas très bien. La version 2.0.8.1283 de PostSharp a réglé le problème. J'évaluerais prudemment comment tout deux outils de réécriture de l'IL s'entendent bien, cependant.

Jusqu'à présent, les avantages l'emportent sur les risques.

Répondre aux préoccupations dépassées soulevées dans d'autres réponses :

• La documentation de Code Contracts est assez complète, mais malheureusement en PDF.
• Il y a au moins un Forum du contrat de code hébergé par Microsoft.
• Code Contracts Standard Edition est gratuit si vous avez une licence VS2010.
• .NET 4 est sorti. Je me suis heurté aux contrats de Microsoft lors de l'implémentation d'interfaces de collecte génériques.

Answer 2

J'ai moi-même joué un peu plus avec les contrats de code sur un petit projet autonome modérément complexe, qui doit hériter de certaines classes BCL et en utiliser d'autres.

Le système de contrats semble génial lorsque vous travaillez dans un environnement complètement isolé, avec seulement votre propre code et vos types primitifs, mais dès que vous commencez à utiliser des classes BCL (qui, jusqu'à .NET 4.0, n'ont pas leurs propres contrats), le vérificateur ne peut pas vérifier si elles violent l'une des exigences/garanties/invariantes et vous recevez donc de nombreux avertissements sur des contraintes potentiellement non satisfaites.

D'autre part, il trouve certaines contraintes invalides ou potentiellement insatisfaites qui pourraient être de véritables bogues. Mais il est très difficile de les trouver car il y a tellement de bruit qu'il est difficile de trouver celles que l'on peut corriger. Il est possible de supprimer les avertissements des classes de la BCL en utilisant le mécanisme assume, mais cela va un peu à l'encontre du but recherché car ces classes auront des contrats dans le futur et les assumptions diminueront leur valeur.

J'ai donc le sentiment que, pour l'instant, étant donné que nous essayons, dans la version 3.5, de nous appuyer sur un cadre que le vérificateur ne comprend pas suffisamment, il vaut probablement mieux attendre la version 4.0.

Answer 3

Jugement par ce fil Je dirais qu'il n'est pas assez mûr pour être utilisé dans le cadre d'un projet d'entreprise. Je ne l'ai pas utilisé moi-même, mais les gens rencontrent encore des bogues qui mettraient un terme à un projet critique pour les contrats. Ce cadre semble vraiment génial et les vidéos d'exemple qu'ils ont fournies sont passionnantes, mais j'attendrais :

• Existence d'un forum communautaire. Vous voudrez pouvoir discuter des problèmes inévitables que vous rencontrez avec d'autres développeurs, et vous voudrez savoir qu'il existe une base de développeurs relativement solide avec laquelle vous pourrez discuter des solutions.
• Libération d'un projet pilote réussi. En général, lorsque Microsoft Research publie un produit qu'il estime suffisamment mature pour être utilisé dans un projet commercial, il travaille avec une organisation pour le piloter, puis publie ce projet en open source pour servir de preuve de concept et d'essai de toutes les principales fonctionnalités. Cela permettrait d'avoir la certitude que la plupart des scénarios contractuels courants sont couverts et fonctionnent.
• Une documentation plus complète. En clair, à un moment donné, vous voudrez faire quelque chose avec les contrats que vous ne pouvez pas encore faire avec Microsoft Code Contracts. Vous voulez être capable de raisonner rapidement et clairement que votre scénario est pas encore pris en charge. À mon avis, la documentation actuelle vous poussera à essayer différentes choses, ce qui vous fera perdre beaucoup de temps.

Answer 4

Ce n'est pas assez mature.

Il le sera dès que Microsoft le publiera avec les éditions abordables de VS, mais sans l'analyse statique du code, il n'est pas du tout utilisable.

Les éditions de VS qui en sont dotées sont tellement chères que seule une poignée de personnes pourront se l'offrir.

C'est une honte que Microsoft ait tué cette idée géniale avec sa politique de prix. J'aimerais que les contrats de code se généralisent, mais ce ne sera pas le cas.

Echec épique.