Насколько зрела платформа Microsoft Code Contracts?

Question

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

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

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

• Какие преимущества вы получили от этого?

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

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

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

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

Answer 1

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

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

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

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

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

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

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

становится:

Contract.Requires(arg != null);

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

Пока что я столкнулся с двумя проблемами:

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

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

Пока что преимущества перевешивают опасности.

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

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

Answer 2

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

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

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

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

Answer 3

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

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

Answer 4

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

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

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

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

Epic fail.