Яка мета аналізу коду та коли мені потрібно його використовувати?

Я чув про аналіз коду Visual Studio, але жодного разу не використовував. Я читав MSDN , але все ще не розумію реального використання аналізу коду.

Хіба це не те саме, що і StyleCop?

Десь згадували і FxCop. Чим відрізняється аналіз коду?

Чи потрібно використовувати аналіз коду для кожного проекту? Чи недостатньо перевірених кодами моїх колег?

Що таке аналіз коду?

Аналіз коду (раніше FxCop) - це інструмент статичного аналізу , який шукає загальні шаблони, які можуть свідчити про те, що у вихідному коді щось не так. Наприклад, якщо екземпляр класу, який реалізує IDisposable, не розміщений належним чином, аналіз коду надсилатиме попередження:

private void DoSomething()
{
    var connection = new SqlConnection(...);
    this.ChangeSomeData(connection);
}

Це правильна реалізація попереднього фрагмента коду:

private void DoSomething()
{
    using (var connection = new SqlConnection(...))
    {
        this.ChangeSomeData(connection);
    }
}

Як і будь-який інструмент статичного аналізу, аналіз коду призначений для пошуку моделей, які громіздко (або просто нудно) знайти вручну. Наприклад, у попередньому прикладі розробнику може бути досить нудно перевірити, чи використовується який-небудь клас, який він використовує IDisposable(або запам'ятати всі класи .NET Framework, які його реалізують).

Які проекти мають право?

Хоча воно підлягає помилковим позитивам, як і будь-який інструмент статичного аналізу, зазвичай вигідно орієнтуватися на нульові попередження для критично важливого для бізнесу коду, не використовуючи придушення . У Visual Studio аналіз коду може бути налаштований на запуск під час компіляції; якщо в настройках проекту також вказано, що попередження слід трактувати як помилки, порушення правил аналізу коду не залишаться непоміченими.

Оскільки статичний аналіз може зайняти деякий час для середніх або великих проектів, часто корисно перемістити його з машин розробника на сервер збирання TFS. Хоча виконання аналізу коду під час попередньої фіксації не є хорошою ідеєю (на відміну від StyleCop), він все ще може працювати на збірці та виходити з ладу, якщо знайдеться попередження.

Для некритичного коду аналіз коду може бути виконаний вручну з Visual Studio або командного рядка. Перевірки та попередження можуть бути чітко викладені у властивостях проекту відповідно до ваших потреб. Наприклад, попередження про глобалізацію можна вимкнути, якщо ваш проект не планується локалізувати.

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

Чи відрізняється він від StyleCop?

Зауважте, що аналіз коду - це не те саме, що і StyleCop . Перша відмінність полягає в тому, що аналіз коду працює з складеною збіркою, тоді як StyleCop працює з самим джерелом. Друга (і найважливіша) відмінність полягає в тому, що аналіз коду шукає малюнки, які можуть вказувати на помилку, тоді як StyleCop просто виконує правила стилю - просту умову, яку використовує ваша команда.

Аналіз коду також особливо корисний для початківців, які не дуже добре знають мову , оскільки часто це може призвести до "Ага!" моменти. Наприклад, CA2105: Поля масиву не слід читати, це може призвести когось до відкриття, що навіть якщо масив позначений лише для читання, він не робить його непорушним, оскільки ніщо не забороняє змінювати елементи в масиві. StyleCop не призводить до відкриттів: немає нічого цікавого в тому, щоб знати, що поля починаються з малої літери або що місцеві дзвінки мають бути встановлені з префіксом this.

Навіть якщо деякі правила виконуються як за допомогою аналізу коду, так і для StyleCop (наприклад, CA1707: Ідентифікатори не повинні містити підкреслення проти SA1310: Імена полів не повинні містити підкреслення ), ці два інструменти є додатковими та часто використовуються поряд.

У нас уже є огляди коду

Наявність оглядів коду не є причиною уникати аналізу коду. Як аналіз коду, так і StyleCop чудово знаходять речі автоматично перед оглядом коду. Немає нічого гіршого, ніж витратити на перевірку коду проблеми, які точно визначають стиль або проблемні зразки, які можна було знайти автоматично. Тримайте огляди коду для цікавих речей.

Інший аспект полягає в тому, що рецензенти людини не обов'язково добре виявляють проблеми, виявлені за допомогою аналізу кодексу. Наприклад, екземпляр реалізації класу IDisposableможе бути створений в одному місці, а потім розміщений в іншому місці. Рецензент знадобиться деякий час, щоб знайти його, тоді як для статичного інструменту аналізу знадобиться всього кілька мілісекунд.