Мы выпускаем новый продукт - CodeRush для Рослин (Дальше ЦRR ).
Первая часть речь шла о Unit Test Runner, а в этой статье мы поговорим о функциях CRR, которые помогают улучшить качество кода:
- Статический анализ.
- Программа проверки орфографии.
- Соглашения об именах.
- Анализ покрытия кода тестами (Test Coverage).
Статический анализ
Visual Studio проверяет ваш код по мере его ввода.Например, в списке ошибок для этого фрагмента кода появится предупреждение.
Переменная testValiable объявлена, но никогда не используется (CS0168).
.
В Visual Studio 2015 генерация таких ошибок реализована в специальных классах, называемых Анализатор кода Roslyn .
Анализатор кода, проще говоря, является частью реализации шаблона «Посетитель» для синтаксического дерева Roslyn. Но если вы выполните поиск в MSDN по коду ошибки CS0168 , есть вот этот статья , в этом CS0168 называется «Предупреждение компилятора», а не Анализатор или Диагностика , как это принято в Рослине.
Это связано с тем, что CS0168 появилась в то время, когда Visual Studio еще не использовала Roslyn, и эта ошибка была обнаружена на этапе частичной компиляции кода.
Мы не будем вдаваться в подробности, но полезно знать, что в Visual Studio 2015 почти все сообщения в списке ошибок генерируются с помощью Анализаторы кода Roslyn .
Вы можете прочитать о них больше здесь .
Полный список стандартных диагностик для .
NET можно найти здесь .
CRR добавляет в этот набор следующую диагностику: 
Этот скриншот был сделан из стандартного редактора набора правил студии, т. е.
если вы используете анализатор кода студии, просто добавьте диагностику CRR в свой набор правил.
Давайте проверим проект Открытая обложка с помощью стандартной диагностики Visual Studio. Для этого откройте свойства решения и установите настройки, как показано на картинке.
И в результате мы получим около тысячи сообщений в Error List. 
Тысяча сообщений не предел, потому что использовался не самый большой набор диагностики.
Однако важно не количество диагностик, а их качество.
Привлекать внимание разработчика следует только тогда, когда это действительно необходимо.
Давайте попробуем проанализировать Открытая обложка воспользовавшись нашей диагностикой.
Есть три способа сделать это:
- Запуск сканирования вручную.
- Проверка в фоновом режиме.
- Проверяю из консоли.
Запуск сканирования вручную
Если проект большой, статический анализ в фоновом режиме может помешать нормальной работе Visual Studio. Это связано с тем, что диагностики расширяют синтаксические деревья и в некоторых ситуациях это приводит к значительному потреблению памяти.После проверки полные синтаксические деревья больше не нужны и память освобождается.
Но это создает трафик памяти и приводит к тому, что большая часть вычислительных ресурсов тратится на сбор мусора.
Режим ручной проверки сделает предсказуемыми моменты, когда Visual Studio работает медленно.
Для запуска статического анализа в этом режиме необходимо нажать на кнопку Обновить в окне Проблемы с кодом (кнопка Обновить первый слева).
Также предусмотрен ручной запуск диагностики.
Но в этом случае вам придется добавить диагностику CRR в набор правил, как описано.
здесь .
Проверка в фоновом режиме
Visual Studio имеет стандартный механизм выполнения статического анализа кода в фоновом режиме.Этот механизм описан здесь .
Как уже упоминалось, проверка фона в крупных проектах может привести к зависанию студии.
Включайте с осторожностью.
Для того чтобы диагностика CRR выполнялась в этом режиме, необходимо установить опцию Включите диагностику CodeRush в фоновый анализ VisualStudio. .
Проверка с консоли
CRR включает исполняемый файл, который можно запустить из командной строки на компьютере разработки или на сервере сборки.Файл называется DevExpress.StaticCodeAnaанализ.
exe .
Вы можете найти его в каталоге плагина (вы можете открыть его из КодРаш | Поддерживать | Папка расширения.
).
Файл представляет собой полностью автономную консольную версию диагностики CRR. Для работы не требуются дополнительные файлы.
Благодаря этому его можно легко интегрировать в любую сборочную систему.
Просто скопируйте DevExpress.StaticCodeAnaанализ.
exe на сервер сборки и введите простой вызов в сценарий сборки: DevExpress.StaticCodeAnalysis.exe EditorsDemos\EditorsSamples_CS.sln results.txt
В результате в результаты.
txt По результатам проверки будет сформирован отчет.
Результаты теста
Мы не гонимся за количеством диагностик, а внедрили только действительно полезные, уделяя большое внимание ложным срабатываниям.Результат проверки источника Открытая обложка показано ниже.
Было всего пару странных мест: 
В этом разделе диагностического кода было обнаружено, что Текущая культура И ТекущаяUIкультура назначен дважды.
Диагностика сработала корректно, но видимо это сделано для того, чтобы получить текст исключения на английском языке.
Второе странное место было обнаружено при тестах.
Переменная результат назначен дважды.
Диагностика сработала корректно, хотя автор теста в комментариях написал, что так и было задумано.
Отличные результаты – ни одного ложного срабатывания.
Проверка нейминга и опечаток в именах
В CRR проверка именования и орфографии также реализована в виде Анализатор кода Roslyn .Эти проверки отключены по умолчанию, поскольку перед их использованием требуется настройка.
Например, если вы включите его без настроек в проекте Открытая обложка , Список ошибок будет содержать огромное количество сообщений о нарушениях правил именования.
Для настройки правил именования есть страница по адресу Параметры .
Здесь вы можете включить и настроить проверки именования типов, пространств имен, свойств и т. д. 
Проверка орфографии реализована в ядре DevExpress проверка правописания .
Опечатки появляются в Списке ошибок, а также выделяются в коде волнистой линией.
В контекстном меню программа проверки правописания генерирует список предлагаемых замен.
Проверка покрытия кода тестами
Помимо диагностики, есть еще один способ улучшить ваш код. Это покрытие кода тестами.В предыдущая статья был смотр возможностей нашего Тестовый бегун , но о запуске тестов с анализом покрытия речи не шло.
В Тестовый бегун Есть режим тестового запуска, в котором инструментируется код. В этом режиме запуск тестов занимает больше времени, поэтому для запуска тестов с анализом покрытия предусмотрены отдельные кнопки.
Репортаж можно посмотреть в Окно инструмента покрытия кода .
На этом снимке экрана видно, что ветвь условия else во втором цикле не покрывается тестами.
По результатам анализа покрытия обычно пишутся новые тесты, увеличивающие процент покрытия.
Следует помнить, что 100%-ное покрытие кода тестами не гарантирует отсутствия в нем проблем.
Например, этот фрагмент кода имеет высокий процент покрытия.
Но среди тестов нет ни одного, проверяющего условное ветвление при срабатывании условия.
if(_domain == null) return;
А если бы покрытие рассчитывалось не по операторам, а по ветвям условных операторов, то цифра была бы другой.
CodeRush для Roslyn — это новый удобный инструмент, который помогает писать правильный код и исправлять проблемы в существующем коде.
Вы можете скачать и попробовать его на Галерея Visual Studio .
В следующей части , давайте посмотрим на возможности CRR по навигации по коду.
Теги: #статический анализ кода #статический анализ кода #открытый исходный код #OpenCover #CodeRush #.
NET #C++
-
Что Такое Realaudio?
19 Oct, 24 -
Откуда В Google Взялись Ненадежные Тесты?
19 Oct, 24 -
Что Такое «Хороший Программист»?
19 Oct, 24 -
Bing Работает И Доступен Каждому!
19 Oct, 24
