CodeRush for Roslyn: Part 2 — огляд фіч для кращого коду

Ми випускаємо новий продукт — CodeRush for Roslyn https://www.devexpress.com/Products/CodeRush/coderush-for-roslyn.xml (далі CRR).



У цій статті піде мова піде про фичах CRR, які допомагають покращувати якість коду:
  • статичний аналіз(Static Analysis);
  • перевірка орфографії(Spell Checker);
  • перевірка іменування(Naming Conventions);
  • аналіз покриття коду тестів(Test Coverage).
Всі приклади в статті зроблено в Visual Studio 2015 на вихідні коди проекту OpenCover.

Статичний аналіз
Visual Studio перевіряє код при наборі. Наприклад, для цього фрагмента коду в Error List з'явиться попередження The variable 'testValiable' is declared but never used (CS0168).



У Visual Studio 2015 формування таких помилок реалізовано в спеціальних класах, які називаються Roslyn Code Analyzer. Code Analyzer -це, спрощено кажучи, частина реалізації патерну Visitor для Roslyn Syntax Tree. Але якщо пошукати в MSDN за кодом помилки CS0168, знайдеться ця стаття, в ній CS0168 називають Compiler Warning, а не Analyzer або Diagnostic, як прийнято в Roslyn. Це пов'язано з тим, що CS0168 з'явився в ті часи, коли в Visual Studio ще не використовувався Roslyn, і ця помилка виявлялася на етапі часткової компіляції коду. Не будемо заглиблюватися далі у деталі, але корисно знати, що в Visual Studio 2015 майже всі повідомлення в Error List формуються з допомогою Roslyn Code Analyzers. Детальніше про них можна почитати тут. Повний список стандартних діагностик .NET можна знайти на тут. CRR додає до цього набору наступні діагностики:



Цей скріншот зроблений із стандартного студійного ruleset-редактора, т. е. якщо ви користуєтеся студійним аналізатором коду, досить додати CRR діагностики в ваш ruleset.

Перевіримо проект OpenCover використовуючи стандартні діагностики Visual Studio. Для цього треба відкрити властивості Solution і виставити налаштування, як показано на картинці.


І, в результаті, отримаємо близько тисячі повідомлень в Error List.



Тисяча повідомлень — не межа, тому що використовувався не самий великий набір діагностик. Однак, важливо не кількість діагностик, а їх якість. Привертати увагу розробника варто, тільки коли це дійсно потрібно.
Спробуємо проаналізувати OpenCover використовуючи наші діагностики. Є три способи зробити це:
  • Запуск перевірки вручну
  • Перевірка на тлі
  • Перевірка з консолі


Запуск перевірки вручну

Якщо проект великий, статичний аналіз тлі може заважати нормальній роботі Visual Studio. Це пов'язано з тим, що діагностики розгортають синтаксичні дерева і в деяких ситуаціях це призводить до значного споживання пам'яті. Після перевірки повні синтаксичні дерева стають непотрібними, і відбувається вивільнення пам'яті. Але це створює трафік пам'яті, і призводить до того, що велика частина обчислювальних ресурсів буде витрачатися на збірку сміття. Ручний режим перевірки зробить передбачуваними моменти коли Visual Studio працює повільно. Для запуску статичного аналізу в цьому режимі, треба натиснути на кнопку Refresh у вікні Code Issues. Кнопка Refresh перша зліва.



Також ручний запуск діагностик передбачений в інтерфейсі Visual Studio. Але в цьому випадку доведеться додати CRR діагностики в ruleset як описано тут

Перевірка на тлі



У Visual Studio є стандартний механізм виконання статичного аналізу коду у фоновому режимі. Цей механізм описаний тут. Як вже було сказано, перевірка на тлі великих проектах може викликати фризи студії. Вмикайте з обережністю. Щоб CRR діагностики виконувалися в цьому режимі, необхідно виставити опцію Include CodeRush diagnostics into the VisualStudio bakground analysis.



Перевірка з консолі

У складі CRR є виконуваний файл, який можна запустити з командного рядка на машині розробника або на сервері складання. Файл називається DevExpress.StaticCodeAnalysis.exe. Знайти його можна в директорії плагіна (можна відкрити з CodeRush | Support | Extension Folder...). Файл являє собою повністю автономну консольну версію CRR діагностик. Ніяких додаткових файлів для його роботи не потрібно. Завдяки цьому він легко інтегруються в будь-яку систему складання. Досить скопіювати DevExpress.StaticCodeAnalysis.exe на сервер складання і вписати простий виклик в складальний скрипт:
DevExpress.StaticCodeAnalysis.exe EditorsDemos\EditorsSamples_CS.sln results.txt 

В результаті в results.txt буде сформовано звіт з результатами перевірки.

Результати перевірки
Ми не женемося за кількістю діагностик, а реалізували лише дійсно корисні, приділивши багато уваги помилкових спрацьовувань. Результат перевірки вихідного OpenCover показаний нижче.



Знайшлося всього пару дивних місць:



У цьому ділянці коду діагностики виявили, що CurrentCulture і CurrentUICulture присвоюється двічі. Діагностика відпрацювала коректно, але судячи по всьому, це робиться для того, щоб отримати текст Exception англійською.
Друге дивне місце знайшлося в тестах.



Змінна result присвоюється два рази. Діагностика відпрацювала коректно, хоча автор тесту в коментарях написав, що так і задумано. Відмінний результат — жодного помилкового спрацьовування.

Перевірка іменування і помилок у назвах
У CRR перевірка іменування і перевірка орфографії так само реалізовані у вигляді Roslyn Code Analyzer. Ці перевірки за замовчуванням, тому що перед їх використанням необхідна настройка. Наприклад, якщо включити без налаштування на проекті OpenCover, Error List буде величезна кількість повідомлень про порушення правил іменування. Для налаштування правил іменування є сторінка в Options. У неї можна включити і налаштувати перевірку іменування типів, просторів імен, властивостей і так далі.



Перевірка правопису реалізована на ядрі DevExpress Spellchecker. Помилки потрапляють в Error List, а так само виділяються в коді хвилястою лінією. У контекстному меню Spellchecker формує список можливих замін.



Перевірка покриття коду тестами
Крім діагностик є ще один спосіб поліпшити свій код. Це покриття коду тестами. попередній статті був огляд можливостей нашого Test Runner, але про запуск тестів з аналізом покриття не розповіли. У Test Runner є режим запуску тестів, в якому проводиться инструментирование коду. У цьому режимі прогін тестів займає більше часу, тому для запуску тестів з аналізом покриття передбачені окремі кнопки.



Покриття можна подивитися в Code Coverage Tool Window. На цьому скріншоті видно, що тестами не покрита гілка else умови у другому циклі.



За результатами аналізу покриття зазвичай пишуть нові тести, які збільшують відсоток покриття. Слід пам'ятати, що 100% покриття коду тестами не гарантує відсутність проблем у ньому. Наприклад, цей фрагмент коду має високий відсоток покриття.



Але серед тестів немає такого, який перевіряє умовне розгалуження, коли спрацьовує умова
if(_domain == null) return; 

І якби покриття вважали не по операторам, а за ветвлениям умовних операторів, то цифра була б іншою.

CodeRush for Roslyn — новий зручний інструмент, який допомагає писати правильний код і виправляти проблеми в існуючому. Скачати можна спробувати Visual Studio Gallery .
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.