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

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

Считаете ли вы, что структура достаточно зрелая для крупных и сложных коммерческих проектов?
Какие проблемы вы столкнулись при использовании?
Какие выгоды вы получили от него?
В настоящее время больнее, чем стоит?

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

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

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

Ответ 1

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

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

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

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

Ответ 2

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

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

Я понимаю, что это скорее обновление от "безвредного" до "в основном безвредного".

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

Мы используем режим "Не переписываем мой релиз IL".

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

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

становится:

Contract.Requires(arg != null);

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

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

У меня был unit test, который полагался на невыполнение контракта. Вы можете утверждать, что наличие теста было ошибкой, но я хотел записать этот конкретный запрет в форме теста. Тест завершился неудачно на моем сервере сборки, потому что у меня не было установленных инструментов. Решение: установите инструменты.
Мы используем два инструмента, которые переписывают IL: Контракты кода и PostSharp. Они не ладили слишком хорошо. PostSharp 2.0.8.1283 исправил проблему. Я бы осторожно оценил, как работают все два инструмента перезаписи IL.

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

Устранение устаревших проблем, поднятых в других ответах:

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

Ответ 3

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

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

Ответ 4

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

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

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

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

Эпический сбой.