#c_sharp #visual_studio
Вопрос теоретический. В студии есть раздел меню Анализ, в этом разделе мне понятны
только функции очистить код и Профилировщик производительности, Собственно вопрос как
пользоваться анализом кода и что он дает.
Ответы
Ответ 1
Анализ кода нужен, чтобы проверять код и выявлять возможные ошибки и нарушения его правильности и соответствия лучшим практикам (например, в плане архитектуры или стиля). В современных версиях студии (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# он бесполезен. "Выполнить анализ кода и подавить активные ошибки" позволяет пометить все текущие ошибки как игнорируемые, в случае, если мы не собираемся их исправлять. "Настроить анализ кода" - это просто другой вариант открыть аналогичную страницу свойств проекта. "Вычислить метрики кода" - рассчитывает какие-то количественные показатели для кода, в том числе на уровне проектов и классов. Практическая ценность сомнительна, но по крайней мере можно быстро посчитать число строк кода. Документация по анализу кода
Комментариев нет:
Отправить комментарий