Comments 11
free версия анализатора не планируется?
Кушать хочется. :)
Если хочется попробовать — проще взять триал.
Если речь именно о регулярном бесплатном использовании — в этой статье разобрано несколько вариантов (для студентов, некоммерческих проектов и т. п.).
Было бы интересно прочитатать если бы вы опубликовали сравнение вашего анализатора, SonarCube, и Microsoft.CodeAnalysis.NetAnalyzers.
Вопрос сравнения хороший, спасибо.
На самом деле коллеги уже проходили это на примере C++ анализатора. Ответ — в заметке “Почему мы не пишем о сравнении PVS-Studio с другими статическими анализаторами кода”.
Однако мне захотелось переосмыслить тему сравнения.
Комментарий получается большим, пришлось даже открыть Word, чтобы всё сформулировать. :)
Чуть позже напишу его в этой же ветке.
Тема сравнения инструментов на самом деле сложная. :(
Анализаторы — инструменты комплексные. То есть это не только про “выдать предупреждение”, но и про удобство интеграции, производительность, разные доп. возможности (типа лёгкого старта) и т. п.
Можно, конечно, всё свести к одним только возможностям анализа: чтобы предупреждения выдавал и не фолсил. Однако я думаю, это будет не совсем корректно.
Если всё-таки браться сравнивать инструменты исключительно по тем предупреждениям, которые они выдают — это тоже та ещё работёнка. Просто сравнить количество предупреждений — не вариант. Нужно тщательно анализировать вывод: смотреть true positives, false positives, а по-хорошему — и false negatives (хотя бы отталкиваясь от true positives других инструментов).
Окей, допустим, решили посмотреть true positives. Тут тоже начинаются интересности: одну и ту же ошибку разные инструменты скорее будут всего подсвечивать разными сообщениями, а вероятно — ещё и выдавать их на разные строки. Этой темы я касался в докладе "Как устроено тестирование средства статического тестирования", когда рассказывал про тестирование на бенчмарках.
Допустим, сделали сравнение, потратили кучу сил и времени.
Побеждает PVS-Studio. Какая будет реакция? Скорее всего что-то вроде: “Ага, ну конечно. Статью же люди из PVS-Studio писали — какие неожиданные результаты…”.
Побеждает не PVS-Studio. Тут у меня, как заинтересованного лица, появляется сильное желание улучшить анализатор, чтобы он показал себя лучше. Почти 8 лет жизни в продукт вложено — шутка ли? :)
Получается, что я пришёл примерно к тому же, что описано в первом пункте статьи “Почему мы не пишем о сравнении PVS-Studio с другими статическими анализаторами кода”. Это хорошо — кажется, она не потеряла своей актуальности. :)
Как же быть?
Если рассматривать вопрос с прагматической точки зрения, я бы переформулировал его так: "Какой из анализаторов принесёт больше пользы на нашем проекте: A, B или C?"
Как это понять? Попробовать. :)
P.S. Если решите попробовать PVS-Studio, рекомендую полистать заметку: "PVS-Studio: 2 фишки для быстрого старта". Она небольшая, но рассказывает о двух важных механизмах, которые сделают знакомство приятнее.
P.P.S. И ещё стоит помнить о философии статического анализа.
Скорее всего многие из ошибок были подсвечены "warning"-ами самой средой разработки (или ее плагином). Но как говорится: "Я работаю как все - на отъебись". К сожалению, с таким отношением к коду/работе частенько сталкиваюсь :-(
Скорее всего многие из ошибок были подсвечены "warning"-ами самой средой разработки (или ее плагином).
Когда я разбирал логи анализатора, то работал в Visual Studio. Насколько я помню, в текстовом редакторе она ни одного из выписанных мест не подсветила.
Что из этого детектит Rider, а что нет — сказать не могу. В любом случае, факт в том, что всё описанное ушло в релиз. :)
К сожалению, с таким отношением к коду/работе частенько сталкиваюсь :-(
Интересно, если поделитесь мыслями на этот счёт: что с этим делать?
>> Когда я разбирал логи анализатора, то работал в Visual Studio ... она ни одного из выписанных мест не подсветила.
Я джавист и работаю в Idea, и она достаточно хороша (а можно еще и добавить/включить дополнительные плагины), но люди кладут прибор на ее warnings (компилится, да еще и работает)
>> Интересно, если поделитесь мыслями на этот счёт: что с этим делать?
Не знаю, к сожалению :-( Если вы тимлид и имеете власть, то можете попробовать включить TreatWarningsAsErrors у всех (как написал @nronnie), ну а также выставить жесткие правила на build-server (TeamCity/Jenkins/или что там у MS). А в целом это вопрос из разряда "Как заставить людей не мусорить/воровать и быть хорошими? :-) "
"На от...бись" лечится флагом
<TreatWarningsAsErrors>true</TreatWarningsAsErrors>
в файле Directory.Build.props всего солюшена :)
.NET 7: разбираем ошибки и подозрительные места в исходниках