validation - Quelle est la maturité du framework Microsoft Code Contracts?




.net-4.0 code-contracts (3)

A en juger par ce fil, je dirais qu'il n'est pas assez mature pour un projet d'entreprise. Je ne l'ai pas utilisé moi-même, mais les gens sont toujours confrontés à des bugs qui mettraient un terme à votre projet. Cela semble être un très bon cadre et les exemples de vidéos qu'ils ont fournis ont été excitants, mais j'attendrais:

  • Existence d'un forum communautaire. Vous voudrez être capable de discuter des problèmes inévitables que vous rencontrez avec d'autres développeurs, et vous voulez savoir qu'il existe une base suffisamment forte de développeurs pour discuter des solutions.
  • Une version réussie du projet pilote. Généralement, lorsque Microsoft Research publie quelque chose qui, selon lui, est suffisamment mature pour être utilisé dans un projet commercial, il travaille avec une organisation pour le piloter, puis publie le projet open source comme preuve de concept et essai au feu. de toutes les principales caractéristiques. Cela donnerait beaucoup de confiance que la plupart des scénarios de contrats communs sont couverts et fonctionnent.
  • Documentation plus complète Clair et simple, à un moment donné, vous allez vouloir faire quelque chose avec des contrats que vous ne pouvez pas encore faire en utilisant les contrats de code Microsoft. Vous voulez être en mesure de rapidement et clairement raison que votre scénario n'est pas encore pris en charge. La documentation actuelle va vous permettre de deviner et d'essayer différentes choses, cependant, à mon avis, ce qui se traduira par beaucoup de temps perdu.

Microsoft a récemment publié une version de son framework Code Contracts sur DevLabs avec une licence commerciale. Nous sommes intéressés à les utiliser dans notre projet (principalement C #, un peu de C ++ / CLI) pour remplacer graduellement tout le code de validation personnalisé, mais je tiens à connaître l'expérience que d'autres personnes ont eu avant de s'y engager, Plus précisément:

  • Pensez-vous que le cadre est suffisamment mûr pour les projets commerciaux de grande envergure et complexes?

  • Quels problèmes avez-vous rencontré en l'utilisant?

  • Quels avantages en avez-vous?

  • Est-il actuellement plus de douleur que cela en vaut la peine?

Je réalise que c'est une question quelque peu subjective car elle nécessite une opinion, mais étant donné que ce framework est une partie très importante de .NET 4.0 et changera (potentiellement) la façon dont nous écrivons tous le code de validation, j'espère que cette question sera laissée ouvert à recueillir de l'expérience sur le sujet pour m'aider à prendre une décision à une question spécifique, répondant:

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

Notez que nous ne livrons pas une API de code, seulement un service Web, donc pour la majorité de la compatibilité de rupture de code en termes de type d'exception levé n'est pas un problème. Cependant, comme j'espère que plus de gens que moi profiteront de ce post et de ses réponses, tout détail dans ce domaine est le bienvenu.


Ce n'est pas assez mature.

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

Les éditions de VS, qui en sont, sont si follement dispendieuses que seule une poignée de personnes pourra jamais se le permettre.

C'est une honte que Microsoft ait tué cette idée incroyable avec leur politique de prix. Je souhaite que les contrats de code deviennent courants, mais ils ne le feront pas.

Échec épique.


La dernière réponse mûre à ceci était en 2009, et .NET 4 est dehors. Je pense que nous devons faire une mise à jour:

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

Je me rends compte que c'est quelque peu d'une mise à niveau de "Harmless" à "Mostly Harmless".

La page d'accueil des Contrats de Code contient des liens vers une documentation assez complète au format PDF. La documentation décrit les consignes d'utilisation de la section 5. En résumé, vous pouvez choisir le degré de bravoure que vous avez pour les outils de contrat qui réécrivent votre IL dans vos versions Release.

Nous utilisons le mode "ne pas réécrire ma version IL".

Jusqu'à présent, je profite de cet avantage inattendu: il y a moins de code, donc moins de code à tester . Toutes vos clauses de garde fondent.

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 juste pour atteindre une couverture de 100%.

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

  • J'ai eu un test unitaire qui reposait sur un échec du contrat pour réussir. Vous pourriez faire valoir que l'existence du 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 génération car les outils n'étaient pas installés. Solution: installez les outils.

  • Nous utilisons deux outils qui réécrivent IL: Code Contracts et PostSharp . Ils ne s'entendaient pas trop bien. Le 2.0.8.1283 de PostSharp a résolu le problème. J'évaluerais prudemment comment deux outils de réécriture IL se entendent, 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 Contrats de Code est assez complète, bien que malheureusement en PDF.
  • Il y a au moins un forum de contrat de code hébergé par Microsoft.
  • Code Contracts Standard Edition est gratuit si vous avez une licence VS2010.
  • .NET 4 est sorti. J'ai rencontré les contrats de Microsoft lors de l'implémentation d'interfaces de collecte génériques.




microsoft-contracts