PVS-Studio corporate blog
Open source
.NET
C#
Machine learning
Comments 13
0
А интересно, есть языки программирования, для которых не нужны подобные анализаторы? Т.е. ЯП, которые изначально так спроектированы, что они в принципе не позволяют совершить многие ошибки. Видимо, для этого нужно запретить «ручное» выделение памяти, преобразование типов и т.п. Вместо if/for/… должны быть другие конструкции. И в итоге мы получаем какой-нибудь Haskell с высоким порогом вхождения и вопросами в плане производительности. Вот, сам и ответил на свой вопрос :(
+2
Ada выглядит вполне неплохо в этом плане. Не модно конечно. И не стильно/молодежно, но там в принципе часть вопросов статического анализа как раз закрыта на уровне языка.
+3
Rust много чего проверяет на этапе компиляции и требует явного приведения типов. Он позволяет предотвратить многие ошибки связанные с управлением памятью.
0
в итоге мы получаем какой-нибудь Haskell с высоким порогом вхождения

бескомпромиссненько. следует понимать, что F# (навскидку) уже был внимательно рассмотрен и признан (развёрнутая аргументация прилагается) непригодным?


 вопросами в плане производительности

…неактуальными для 99,9% ПО на рынке (т.к. 99,99% времени это ПО ждёт данных из сети, с диска или от пользователя), но кому какое дело?

+1
У меня в проекте V3062 срабатывает на код вида var vm = container.Get(); vm.Navigate(vm);
При этом, вызываемый метод выглядит как-то так: public void Navigate(T viewModel) { var t = typeof(T);… }
Т.е. параметр viewModel используется в том числе и для получения информации о типе переданного аргумента.
Нельзя ли сделать, чтобы эта диагностика не срабатывала, при условии, что метод не является static, и подозрительный параметр имеет тип из generic определения метода? А описанный сценарий — вынести в другую диагностику, чтобы можно было ее отдельно выключать.
+1
Для такого случая делать исключения, пожалуй, не стоит.
Впрочем спасибо, мы подумаем.
Для устранения FA нужно написать комментарий //-V3062 или комментарий вида //-V:Navigate:3062 в глобальный файл настроек.
0
Мне кажется, что не стоит каждый «всегда лживый/истинный» код считать ошибкой. Иногда это просто защита от дурака. Например, выполнили проверку X0 && Y>0), просто на случай, что кто-нибудь в будущем может, скажем, убрать знак '=' в первой проверку, просто потому что между двумя проверками появится новый код, который будет требовать этого. И вот, из за невнимательности он создал баг, которого можно было избежать за долго до его появления.
К тому же, иногда полная проверка (X>0 && Y>0) имеет какой-то смысл, например в математической формуле и сразу будет бросаться в глаза знающему человеку, который поймет что именно здесь высчитывается та самая часть формулы.
0
Странно, при добавлении комментария часть текста пропала. Имелось в виду «Например, выполнили проверку X<=0 и бросили исключение, а дальше по коду проверили (X>0 && Y>0)»
+1

Да вообще любая «ошибка», выдаваемая статическим анализатором, может оказаться вовсе не ошибкой. В противном случае соответствующую проверку можно было бы встроить в компилятор в виде ворнинга.

Only those users with full accounts are able to leave comments. , please.