PVS-Studio corporate blog
.NET
Visual Studio
C#
Development for Windows
Comments 37
-8
Непонятно, почему RowsCount > 100000 всегда false?

До этого условия просто не дойдет очередь, т.к отработает ветка RowsCount > 20000, но оно может быть и истинным.
+3
Если RowsCount <= 20000, то очередь дойдёт, и условие RowsCount > 100000 всегда будет ложным.
Если же RowsCount > 20000, то очередь действительно не дойдёт, но в таком случае значение RowsCount > 100000 не представляет никакого интереса.
То есть диагностика «условие всегда ложно» неявно подразумевает «когда его будут проверять».
-2
Ну конечно, случай <=20000 я просто не рассматривал по логике дальнейших действий.

Кстати, а в этом случае не обнаружилось, что DatatableUpdateInterval не инициализирована или равна 0, что по логике тоже ошибка? Или же она инициализирована ранее в коде, но не показана?
+2
Ранее она инициализирована значением по умолчанию = 15000
0
Согласен с Siemargl. Почему столько несогласных?

«V3022 Expression 'RowsCount > 100000' is always false. ProcessingEngine.cs 559»

Это неверное утверждение. Выражение само по себе будет истинным при RowsCount свыше 100000, нельзя утвеждать что это «always false». Другое дело, что ветка условия действительно никогда не будет выполнена.

Возможно, было бы лучше перефразировать предупреждение как-нибудь так: «V3022 Unreachable conditional operator branch identified by expression 'Expression 'RowsCount > 100000' (overridden by prior expression 'RowsCount > 20000')».
+3
В ТОТ МОМЕНТ когда будет вычисляться условие RowsCount > 100000, оно ВСЕГДА БУДЕТ ЛОЖНО. Так что всё нормально. Возможно логика сообщений может казаться странной, но на всех всё равно не угодишь. :)
0
Тогда уж лучше написать, что «код недостижим». Иначе человек попадет в ступор. Например он вводит миллион, а программа говорит, что введенное число никогда не будет больше ста.
+7
Тогда что же такое у них все остальные статьи? Обычно в блог PVS-Studio все идут, чтобы поглазеть на занимательные баги, а тут подборка из ТОП-10 багов за всё время. Мне кажется, что это одна из лучших статей в их блоге.
+4
По поводу третьего места, вас не смущает, что в вашем решении если пользователь инициализирует переменную нулем а потом попробует ее получить, то он получит 42?)
get
    {
      if (field == default(Int32))
        field = 42;

      return field;
    }
0
В документации приведен синтетический пример. Конечно, он не идеален. Но смысл — указать на возможный путь обхода проблемы, а конечную логику в каждом конкретном случае придумает сам разработчик. В данном примере можно было бы ввести дополнительный флаг, сигнализирующий об установке переменной значения по-умолчанию (0) в сеттере, и использовать его в геттере.
+1
Как вариант, или сделать int nullable
т.е. вот так в примере
private static Int32? field = 42;
и проверку if (field == null) или же просто return field ?? 42;
Но суть в том, что не очень то хорошо такие примеры приводить, хотя конечно кто будет слепо копировать сам себе злобный буратино =)
0
По поводу 4 места: это же стандартная процедура экранирования служебного символа, нет? Я думаю, автор пытается сделать именно то, что получит — кавычку как часть строки.
0

Чтобы получить кавычку "как часть строки", нужно заменить её на "слэш-кавычку". Т.е. должно быть двойное экранирование: Replace("'", "\\'")

+3
Тут везде ошибка в реализации. Вряд ли статический анализатор укажет на ошибку в задумке. Под «разработчик задумывал не это» имеется в виду «он хотел правильно, но получилось неправильно», кмк
+1
Если вы хотите предложить проект для проверки, пожалуйста воспользуйтесь рекомендациями из нашей недавней статьи
+1

Друзья, пожалуйста, учтите, что код по ссылке на gist не мой, а я просто его вовремя стянул с форума и выложил на всеобщее обозрение (поскольку ссылки с форума на gamedev давно протухли, это вполне полезно). Свой код я так не пишу!

+2

Оффтоп: а неужели нельзя это место на C# как-то поизящнее переписать? Я не настоящий сварщик, но должен же быть способ без адской копипасты.


image

0
Есть небольшая вероятность, что это «auto generation code».
Когда то, я писал создание юнита констант из базы данных, получался примерно такой же код.
0
А у вас есть другой способ проинициализировать 50 полей?
0

Вроде в шарпе были литералы для структур? Но, как я говорил, я не настоящий сварщик.

0

Для начала, все эти _begin/_end/_middle нужно группировать в объекты.


Загрузка из конфига неплохо работает. Или из ресурсов. Или автогенерация подобного же кода — но уже на основе другого файла. Или хотя бы составление всего вот этого в визуальном редакторе...

+4

Ещё один оффтоп :-)


Недавно прочитал статью The Day I Parsed A Monster. Статья об одной из трудностей, с которой столкнулись разработчики X-Ray при проверке .NET Core runtime.


Сама статья несколько раздута (а уж "решение" и вовсе не интересно — замена полноценного парсера десятком микро-грамматик для распознавания структурных единиц: условий, циклов и пр.). Но несколько моментов мне всё же показались интересными:


1) В ходе работы над X-Ray была найдена синтаксическая ошибка в gc.cpp. Я вижу, вы проверяли проекты .NET Core в декабре 2015. Но не смог найти, была ли в ваших отчётах эта ошибка? (я, правда, не очень силён в "топонимике" .NET Core: runtime — это то же самое, что CoreCLR? и если нет, не хотите ли проверить .NET Core runtime?)


2) Автор статьи сокрушается о "неподъёмной" сложности gc.cpp с его 37 тысячами строк кода. Как обстоят дела у PVS-Studio с обработкой файлов таких размеров?


3) Также интересной мне показалась идея отслеживать изменения в коде по логам системы контроля версий с тем, чтобы давать больший приоритет определённым участкам. Правда, это более актуально для анализа сложности, чем для поиска ошибок. Но, быть может, и вам будет интересно реализовать что-то подобное. Скажем, для запуска наиболее ресурсоёмких проверок (в первую очередь) на новых участках кода.


4) А ещё понравилась их диаграмма. Если сделать такую с диагностиками, можно будет одним взглядом оценить, насколько плохи дела в том или ином модуле.


5) Не думали ли вы сделать SaaS версию PVS-Sudio? Чтобы можно было указать ей URL открытого проекта на GitHub или BitBucket и (через какое-то время) получить отчёт.

-8
первое место это тупая попытка рекламы, кто же пишет код, а потом его совсем не тестирует, а попытка втюхать анализатор кода вместо написания тестов как-то сомнительно.
+7
Ох уж мне эти программисты-идеалисты. :) Напоминаю, что мы находим ошибки, в таких проектах, как GCC, GDB, Clang, Qt, Chromium, Boost и так далее. Вы думаете, они не тестирую проекты? :)

-4
а я и не говорил что анализатор плох, а вот писать статьи где основная цель реклама это очень плохо
0
Статический анализ не отменяет необходимость тестов. Статический анализ, это ответ на вопрос: «А что ещё мы можем сделать, чтобы улучшить качество и надёжность?». Статический анализатор не конкурирует с другими методологиями, а дополняет их. В ровно в той же степени, в какой предупреждения компилятора не заменяют и не конкурирует с методологией TDD, или скажем с отладчиком.

Использование статического анализа свидетельствует о зрелости процессов разработки, используемых в компаниях.
0
Решил послать весточку интересующимся анализатором PVS-Studio. Сегодня 06.03.2013 в 15.00 состоится пробный стрим, где можно будет вживую посмотреть на процесс работы PVS-Studio и интерактивно пообщаться. Присоединяйтесь к нашему стриму. Подробности (см. раздел Важно).
Only those users with full accounts are able to leave comments. , please.