В Visual Studio есть Анализ кода, для чего он и в каких ситуациях его использовать

Анализ кода нужен, чтобы проверять код и выявлять возможные ошибки и нарушения его правильности и соответствия лучшим практикам (например, в плане архитектуры или стиля). В современных версиях студии (2017+) анализаторы можно разделить на две группы:

• Анализаторы исходного кода. Эти анализаторы работают в режиме реального времени и могут проверять код, даже если он не компилируется. Специально включать их не нужно, они работают всегда, и с меню Анализ они не связаны. Обычно их предупреждения отображаются как всплывающие подсказки прямо в редакторе кода, реже - в результатах компиляции.

• Анализаторы скомпилированных сборок. Этот вид анализаторов запускается только после сборки проекта и проверяет бинарники на соответствие определенным правилам (в основном по архитектуре), выводя предупреждения в результаты компиляции. Не работает для .NET Core. Меню Анализ управляет именно этими, "старыми" анализаторами.

В каких ситуациях использовать анализаторы? Первого вида - видимо всегда, их даже непонятно как отключить (иногда они падают с ошибкой, выводя сообщение в верхней части окна, и анализ перестает работать сам). Второго вида - в зависимости от требований к проекту. Например, имеет смысл их использовать, если вы делаете библиотеку, которой будут пользоваться другие, а если просто программу для себя - скорее всего, нет.

Использование анализа исходного кода

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

Создадим проект C#, и добавим в него такой код:

using System;
using System.IO;
namespace NetCoreTest
{
    class Program
    {        
        public class foo
        {
             
        }
        static void Main(string[] args)
        {            
            Console.WriteLine("Hello World!");
            Console.ReadKey();
        }
    }
}

Студия подчеркнет пунктирной линией класс, названный с маленькой буквы, а также выведет в список ошибок сообщение с кодом IDE1006. (Коды, начинающиеся с IDE, относятся к стилю.) Если навести мышью на пунктир, появляется всплывающая подсказка, в которой можно выбрать предложенный вариант исправления.

Также неиспользуемую директиву using студия выделила серым цветом. Это предупреждение по умолчанию не отображается в списке ошибок, но оно также имеет код (IDE0005). Аналогично, можно навести мышью и применить исправление, удаляющее неиспользуемую директиву.

После исправления:

using System;
namespace NetCoreTest
{
    class Program
    {        
        public class Foo
        {
             
        }
        static void Main(string[] args)
        {            
            Console.WriteLine("Hello World!");
            Console.ReadKey();
        }
    }
}

Можно установить дополнительные анализаторы, которые будут также проверять архитектуру (у них коды предупреждений начинаются с "CA"). Подробнее см. Install .NET Compiler Platform code analyzers.

Использование анализаторов скомпилированных сборок

Создадим проект .NET Framework, и добавим в него код:

using System;
namespace ConsoleApplication1
{
    public class Program
    {
        public class Foo { }
        static void Main(string[] argv)
        {
            Console.WriteLine("Hello world");
            Console.ReadKey();
        }  
    }
}

Перейдем в свойства проекта, на вкладке Анализ кода установим галку "Включить анализ кода в сборке" и выберем набор правил "Базовые нормы и правила разработки Microsoft" (BasicDesignGuidelineRules.ruleset), или аналогичный более строгий. Выполним сборку проекта. Результат:

Разберем предупреждения:

CA1014: Microsoft.Design : Пометьте 'ConsoleApp1.exe' как CLSCompliant(true), поскольку он предоставляет типы, видимые извне.

Сборка, содержащая открытые типы, должна быть помеченной как соответствующая спецификации CLS. Раз мы пишем не библиотеку, а программу, то открытых типов в ней быть не должно (оставляя пока за скобками удобство модульного тестирования), поэтому исправлять логично не добавлением атрибута, а удалением public с класса Program.

CA1053: Microsoft.Design : Поскольку тип 'Program' содержит только статические члены, пометьте его как статический, чтобы компилятором не был добавлен общий конструктор по умолчанию.

Тут все понятно, у класса Program нет членов экземпляра, поэтому он должен быть static.

CA1801: Microsoft.Usage : Параметр 'argv' в 'Program.Main(string[])' никогда не используется. Удалите этот параметр или используйте его в теле метода.

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

CA1034: Microsoft.Design : Не делайте тип 'Program.Foo' вложенным. Вместо этого измените режим доступа к нему так, чтобы он не был виден извне.

См. Публичные вложенные классы - плохая практика?

Исправлять в случае этого типа анализаторов нужно вручную. Получаем такой код после исправления этих предупреждений (он правда выводит новое, о неиспользуемом классе Foo):

using System;
namespace ConsoleApplication1
{
    static class Program
    {
        class Foo { }
        static void Main()
        {
            Console.WriteLine("Hello world");
            Console.ReadKey();
        }  
    }
}

До сих пор мы не коснулись меню Анализ. Зачем оно нужно? Пункт "Выполнить анализ кода", видимо, рассчитан на те типы проектов, где он не выполняется автоматически при сборке. Для C# он бесполезен. "Выполнить анализ кода и подавить активные ошибки" позволяет пометить все текущие ошибки как игнорируемые, в случае, если мы не собираемся их исправлять. "Настроить анализ кода" - это просто другой вариант открыть аналогичную страницу свойств проекта. "Вычислить метрики кода" - рассчитывает какие-то количественные показатели для кода, в том числе на уровне проектов и классов. Практическая ценность сомнительна, но по крайней мере можно быстро посчитать число строк кода.

Документация по анализу кода