Комментарии 37
До этого условия просто не дойдет очередь, т.к отработает ветка RowsCount > 20000, но оно может быть и истинным.
Если же RowsCount > 20000, то очередь действительно не дойдёт, но в таком случае значение RowsCount > 100000 не представляет никакого интереса.
То есть диагностика «условие всегда ложно» неявно подразумевает «когда его будут проверять».
«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')».
get
{
if (field == default(Int32))
field = 42;
return field;
}
т.е. вот так в примере
private static Int32? field = 42;
и проверку if (field == null) или же просто return field ?? 42;
Но суть в том, что не очень то хорошо такие примеры приводить, хотя конечно кто будет слепо копировать сам себе злобный буратино =)
Стоило бы упомянуть в документации класс ThreadLocal<T>
http://www.gamedev.ru/projects/forum/?id=160897
https://gist.github.com/ForNeVeR/9001938
Друзья, пожалуйста, учтите, что код по ссылке на gist не мой, а я просто его вовремя стянул с форума и выложил на всеобщее обозрение (поскольку ссылки с форума на gamedev давно протухли, это вполне полезно). Свой код я так не пишу!
Кстати, вот статья про разработку этого шедевра: https://nooby-games.ru/щи-симулятор-жестокости/
Оффтоп: а неужели нельзя это место на C# как-то поизящнее переписать? Я не настоящий сварщик, но должен же быть способ без адской копипасты.
Вроде в шарпе были литералы для структур? Но, как я говорил, я не настоящий сварщик.
Для начала, все эти _begin/_end/_middle нужно группировать в объекты.
Загрузка из конфига неплохо работает. Или из ресурсов. Или автогенерация подобного же кода — но уже на основе другого файла. Или хотя бы составление всего вот этого в визуальном редакторе...
Ещё один оффтоп :-)
Недавно прочитал статью 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 и (через какое-то время) получить отчёт.
Использование статического анализа свидетельствует о зрелости процессов разработки, используемых в компаниях.
Топ 10 ошибок в проектах C# за 2016 год