validation - ¿Qué tan maduro es el marco de Microsoft Code Contracts?

.net-4.0 code-contracts

Question

Microsoft ha publicado recientemente una versión de su marco de contratos de código en DevLabs con una licencia comercial. Estamos interesados ​​en usarlos en nuestro proyecto (principalmente C #, algunos C ++ / CLI) para reemplazar gradualmente todo el código de validación personalizado, pero estoy ansioso por conocer la experiencia que otras personas han tenido con él antes de comprometernos con él, específicamente:

• ¿Crees que el marco está suficientemente maduro para proyectos comerciales grandes y complejos?

• ¿Qué problemas has encontrado al usarlo?

• ¿Qué beneficios has obtenido de esto?

• ¿Actualmente es más dolor de lo que vale?

Me doy cuenta de que esta es una pregunta algo subjetiva ya que requiere opinión, pero dado que este marco es una parte muy significativa de .NET 4.0 y (potencialmente) cambiará la forma en que todos escribimos el código de validación, espero que esta pregunta quede abierto para reunir experiencia sobre el tema que me ayude a tomar una decisión sobre una pregunta específica y responsable:

¿Deberíamos comenzar a usarlo el próximo mes?

Tenga en cuenta que no enviamos una API de código, solo una de servicio web, por lo que para la mayoría de la compatibilidad de ruptura de código en términos del tipo de excepción lanzada no es una preocupación. Sin embargo, como espero que más personas que yo solo se beneficien con esta publicación y sus respuestas, cualquier detalle sobre esta área es más que bienvenido.

Answer 1

A juzgar por este hilo , diría que no es lo suficientemente maduro como para utilizarlo en un proyecto de nivel empresarial. No lo he usado yo mismo, pero la gente aún se encuentra con errores que podrían detener su proyecto de contrato crítico. Parece un gran marco y los videos de ejemplo que han proporcionado han sido emocionantes, pero esperaba:

• Existencia de un foro comunitario. Querrá poder hablar de los inevitables problemas que se encuentra con otros desarrolladores, y desea saber que existe una base de desarrolladores bastante buena para analizar soluciones.
• Un lanzamiento exitoso del proyecto piloto. Generalmente, cuando Microsoft Research lanza algo que creen que es lo suficientemente maduro como para ser utilizado en un proyecto comercial, trabajará con una organización para pilotearlo, y luego lanzará ese proyecto de código abierto como una prueba de concepto y ensayo a fuego. de todas las características principales. Esto daría mucha confianza en que la mayoría de los escenarios contractuales comunes están cubiertos y funcionan.
• Documentación más completa. Simple y llanamente, en algún momento querrás hacer algo con contratos que aún no puedes hacer con los Contratos de Código de Microsoft. Desea poder razonar rápida y claramente que su escenario aún no es compatible. Sin embargo, la documentación actual te mantendrá adivinando e intentando cosas diferentes, en mi opinión, lo que resultará en mucho tiempo perdido.

Answer 2

He estado jugando un poco con el código para contratarme un poco en un proyecto independiente pequeño pero moderadamente complejo, que necesita heredar de algunas clases BCL y usar otras.

Lo de los contratos parece genial cuando trabajas en un entorno completamente aislado con solo tu propio código y tipos primitivos, pero tan pronto como comienzas a usar clases BCL (que hasta .NET 4.0 no tienen sus propios contratos) el verificador no puede verificar si van a violar cualquiera de los requisitos / asegura / invariantes y así recibirás muchas advertencias sobre las restricciones potencialmente insatisfechas.

Por otro lado, encuentra algunas limitaciones no válidas o potencialmente insatisfechas que podrían ser errores reales. Pero es muy difícil encontrarlos porque hay tanto ruido que es difícil saber cuáles puedes arreglar. Es posible suprimir las advertencias de las clases de BCL utilizando el mecanismo de suposición, pero esto es algo contraproducente ya que estas clases tendrán contratos en el futuro y las suposiciones disminuirán su valor.

Así que mi sensación es que, por ahora, porque en 3.5 intentamos construir sobre un marco que el verificador no comprende lo suficiente, es probable que valga la pena esperar 4.0.

Answer 3

La última respuesta madura a esto fue en 2009, y .NET 4 está fuera. Me imagino que nos corresponde una actualización:

Los contratos de código bien podrían ser lo suficientemente maduros para sus lanzamientos de Debug.

Me doy cuenta de que esto es algo así como una actualización de "Inofensivo" a "Mayormente inofensivo".

La página de inicio de los Contratos del Código contiene enlaces a documentación completa en formato PDF. La documentación describe las pautas de uso en la sección 5. Para resumir, puede elegir qué valiente se siente con respecto a las Herramientas de contrato que vuelven a escribir su IL en sus compilaciones de Release.

Estamos utilizando el modo "No reescribir mi Release IL".

Hasta ahora, estoy disfrutando más de este beneficio inesperado: hay menos código, por lo tanto, menos código para probar . Todas sus cláusulas de guardia se derriten.

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

se convierte en:

Contract.Requires(arg != null);

Tus funciones son más cortas. Tu intención es más clara. Y ya no tiene que escribir una prueba llamada ArgumentShouldNotBeNull solo para alcanzar el 100% de cobertura.

Hasta ahora, me he encontrado con dos problemas:

• Tuve una prueba de unidad que se basó en una falla de contrato para tener éxito. Se podría argumentar que la existencia de la prueba fue un error, pero yo quería documentar esta prohibición en particular en la forma de una prueba. La prueba falló en mi servidor de compilación porque no tenía las herramientas instaladas. Solución: instala las herramientas.

• Estamos utilizando dos herramientas que reescriben IL: Contratos de código y PostSharp . No se llevaban bien. PostSharp''s 2.0.8.1283 solucionó el problema. Sin embargo, evaluaría cautelosamente cómo se llevan las dos herramientas de reescritura de IL.

Hasta ahora, los beneficios superan los riesgos.

Abordar las preocupaciones desactualizadas planteadas en otras respuestas:

• La documentación de Code Contracts es bastante exhaustiva, aunque lamentablemente en PDF.
• Hay al menos un foro de contrato de código alojado por Microsoft.
• Code Contracts Standard Edition es gratis si tiene alguna licencia VS2010.
• .NET 4 está fuera. Me encontré con los contratos de Microsoft cuando implementé interfaces de colección genéricas.

Answer 4

No es lo suficientemente maduro.

Será tan pronto como Microsoft lo publique con las ediciones asequibles de VS, pero sin el análisis de código estático no es utilizable en absoluto.

Las ediciones de VS, que lo tienen, son tan increíblemente caras que solo unas pocas personas podrán permitírselo.

Es una pena que Microsoft haya eliminado esta increíble idea con su política de precios. Desearía que los Contratos de Código se convirtieran en convencionales, pero no lo serán.

Fallo épico.