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

StackOverflow https://stackoverflow.com/questions/671809

Вопрос

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

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

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

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

  • Неужели сейчас от этого больше боли, чем пользы?

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

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

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

Это было полезно?

Решение 2

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

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

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

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

Другие советы

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

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

Я понимаю, что это своего рода повышение уровня с «Безвредного» до «Практически безвредного».

А Домашняя страница кодовых контрактов ссылки на довольно подробную документацию в формате 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 2.0.8.1283 устранила проблему.Я бы осторожно оценил, насколько любой однако два инструмента переписывания IL уживаются друг с другом.

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

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

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

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

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

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

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

Редакции VS, в которых он есть, настолько безумно дороги, что лишь немногие люди смогут его себе позволить.

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

Эпический провал.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top