Насколько зрелым является структура контрактов Microsoft Code Contracts?

Question

Корпорация Microsoft недавно выпустила свою версию Code Contracts на DevLabs с коммерческой лицензией. Мы заинтересованы в том, чтобы использовать их в нашем проекте (в основном, C#, некоторые C++/CLI), чтобы постепенно заменить весь пользовательский код проверки, но я очень хочу узнать о том, как другие люди сталкивались с ним, прежде чем мы его совершили, в частности:

• Считаете ли вы, что структура достаточно зрелая для крупных и сложных коммерческих проектов?

• Какие проблемы вы столкнулись в процессе его использования?

• Какие преимущества у вас есть?

• В настоящее время больнее, чем это стоит?

Я понимаю, что это довольно субъективный вопрос, как это требует мнение, но, учитывая, что эта структура является очень важной частью .NET 4.0 и (потенциально) изменить способ, которым мы весь код проверки записи, я надеемся, что этот вопрос останется открытым для сбора опыта по этому вопросу, чтобы помочь мне принять решение по конкретному ответственному вопросу:

Должен ли мы начать использовать его в следующем месяце?

Обратите внимание, что мы не отправляем API-интерфейс кода, а только веб-сервис, поэтому для большей части совместимости с кодами с точки зрения типа исключенного типа это не проблема. Однако, поскольку я надеюсь, что больше людей, чем только я, выиграют от этой должности и ее ответов, любая деталь вокруг этой области более чем приветствуется.

Answer 1

Я играю с кодом, который еще больше заключает контракты на небольшом, но умеренно сложном автономном проекте, который необходимо унаследовать от некоторых классов BCL и использовать другие.

Контракты выглядят великолепно, когда вы работаете в полностью изолированной среде с помощью только собственного кода и примитивных типов, но как только вы начнете использовать классы BCL (которые до .NET 4.0 не имеют собственных контрактов) верификатор не может проверить, будут ли они нарушать любой из требований/обеспечения/инвариантов, и поэтому вы получите много предупреждений о потенциально неудовлетворенных ограничениях.

С другой стороны, он находит некоторые недопустимые или потенциально неудовлетворенные ограничения, которые могут быть настоящими ошибками. Но их очень сложно найти, потому что есть так много шума, что трудно узнать, какие из них вы можете исправить. Можно запретить предупреждения из классов BCL с использованием механизма принятия, но это несколько самопровозглашает, поскольку у этих классов будут контракты в будущем, и предположения уменьшат их ценность.

Так что я чувствую, что на данный момент, поскольку в 3.5 мы пытаемся построить фреймворк, который верификатор недостаточно понимает, вероятно, стоит ждать 4.0.

Answer 2

Судя по this thread Я бы сказал, что он недостаточно зрелый, чтобы использовать его для проекта уровня предприятия. Я не использовал его сам, но люди все еще сталкиваются с ошибками, которые остановят ваш критически важный проект. Похоже, действительно большой рамки и пример видео, которые они ввели, были захватывающими, но я бы ждать:

• Существование форума сообщества. Вы захотите обсудить неизбежные проблемы, с которыми сталкиваетесь с другими разработчиками, и вы хотите знать, что существует достойная основа разработчиков, чтобы обсудить решения.
• Успешный выпуск пилотного проекта. Как правило, когда Microsoft Research выпускает что-то, что, по их мнению, достаточно зрело, чтобы использоваться в коммерческом проекте, они будут работать с организацией, чтобы пилотировать ее, а затем опубликовать этот открытый проект с открытым исходным кодом в качестве доказательства концепции и пробной версии, огонь всех основных функций. Это даст большую уверенность в том, что большинство общих сценариев контрактов охвачены и работают.
• Более полная документация. Простой и простой, в какой-то момент вам захочется что-то сделать с контрактами, которые вы еще не можете использовать с помощью контрактов Microsoft Code. Вы хотите быстро и четко определить, что ваш сценарий - , пока не поддерживается. Текущая документация заставит вас угадать и попробовать разные вещи, хотя, на мой взгляд, это приведет к большому количеству потраченного впустую времени.

Answer 3

Это недостаточно зрелый.

Это будет, как только Microsoft выпустит его с доступными версиями VS, но без анализа статического кода он вообще неприменим.

Издания VS, имеющие его, настолько безумно дороги, что только горстка людей когда-либо сможет себе это позволить.

Это позор Microsoft убила эту удивительную идею своей ценовой политикой. Я хочу, чтобы кодовые контракты стали мейнстримом, но они не будут.

Epic fail.

Answer 4

Последний зрелый ответ на это был в 2009 году, а .NET 4 отсутствует. Я полагаю, что мы должны обновить:

Код Контракты вполне могут быть достаточно зрелыми для ваших выпусков отладки.

Я понимаю, что это нечто вроде обновления от «Безвредного» до «В основном безвредного».

Code Contracts home page ссылки на достаточно полную документацию в формате PDF. В документации приведены рекомендации по использованию в разделе 5. Подводя итог, вы можете выбрать, насколько храбрый вы чувствуете об инструментах контракта, переписывающих ваш IL в ваших версиях релиза.

Мы используем режим «не переписываем мой релиз IL».

До сих пор мне больше всего нравилось это неожиданное преимущество: есть меньше кода, поэтому меньше кода для тестирования. Все ваши охранные оговорки тают.

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

становится:

Contract.Requires(arg != null); 

Ваши функции короче. Ваши намерения понятнее. И вам больше не нужно писать тест под именем ArgumentShouldNotBeNull, чтобы достичь 100% покрытия.

До сих пор, я столкнулся с двумя проблемами:

• У меня был тест блок, который полагался на провал контракта, чтобы добиться успеха. Вы можете утверждать, что наличие теста было ошибкой, но я хотел записать этот конкретный запрет в форме теста. Тест завершился неудачно на моем сервере сборки, потому что у меня не было установленных инструментов. Решение: установите инструменты.

• Мы используем два инструмента, которые переписывают IL: Code Contracts и PostSharp. Они не ладили слишком хорошо. PostSharp 2.0.8.1283 исправил проблему. Я бы осторожно оценил, как любой два IL-переписывания инструменты ладят, хотя.

До сих пор преимущества перевешивали опасности.

Адресации неприменяющихся проблемы, поднятые в других ответах: документация

• кодекса контрактов является весьма тщательно, хотя, к сожалению, в формате PDF.
• Существует не менее одного Code Contract forum, размещенного Microsoft.
• Контрактный код Стандартная версия бесплатна, если у вас есть лицензия VS2010.
• .NET 4 отсутствует. Я столкнулся с контрактами Microsoft при реализации универсальных интерфейсов коллекции.