Какова цель анализа кода и когда мне нужно его использовать?

Я слышал об анализе кода в 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может быть создан в одном месте, а затем расположен в другом месте. Рецензенту потребуется некоторое время, чтобы найти его, а инструменту статического анализа потребуется всего несколько миллисекунд для его обнаружения.