Comments
А вы могли бы сделать сравнение количества ошибок для Mono, CoreCLR и Rolsyn? Например в измерении количество серьезных багов на строки кода.
Примерно в виде:
Проект | строк кода | найдено багов | багов на 1000 строк

UPD. Хотя конечно было бы еще интересней посмотреть на все проверенные проекты в сравнении
Можно, но практического смысла в этом для нас нет. Тем более это будет нечестные сравнения. С развитием анализатора мы будем находить всё больше ошибок. Поэтому чем позже будет проверяться проект, тем хуже будет получаться результат.
После Resharper ваш анализатор у нас ничего не нашел. Я сначала думал что не работает — сделал пару описок — обнаружил.

Пока тщательно наблюдаю за проектом. Если будет находить то что не находит Resharper — придется использовать, конечно. Ошибки дорого стоят.
У решарпера и пвс-студио немного разный подход к обнаружению ошибок, поэтому рано или поздно расхождения появятся =)
Решарпер ищет ошибки здесь и сейчас, по мере того, как вы просматриваете / редактируете / пишете новый код. Анализы работают локально и быстро (по крайней мере должны работать быстро).
Пвс-студио работает в другом режиме — она получает на вход уже написанный проект, дальше шуршит некоторое время и выдает сразу список ошибок по всему проекту. Подозреваю (хотя и не знаю наверняка) что их анализы отвечают другим требованиям, нежели наши =)
Ага, работает в фоне и потом выводит сообщение что нашла проблемы в самый неподходящий момент :). Решарпер действует правильнее — сообщает о сомнительном коде сразу как его написали, те сокращает время существования ошибки до 0.
Не все диагностики можно выполнить сразу, как только написана очередная строчка. Всё-таки полноценный статический анализ и подсветка подозрительных мест на лету — это разные вещи.
Именно об этом я и пытался написать… тут нету правильного и не правильного, просто разные подходы и разные анализы
Я думаю, что разработчиков MonoDevelop заставляют использовать MonoDevelop, поэтому ReSharper им недоступен.
Ну может и заставляют. Но vim режим всё равно как отвалился, так и не работает.
Дополню. Vim mode оказывается вообще решили вырезать в шестой версии. Вместо того, чтобы починить.
Небольшая поправка по поводу использования MonoDevelop в Unity3D.
С версии 5.3 в Unity используется MonoDevelop версий 5.x.
За информацию спасибо Lertmind.
Не знаю, почему, но как только вы стали писать про версию PVS Studio для C#, я лично перестал вас читать. Потерялся интерес. Может, просто совпадение. Это не претензия — просто обратная связь; вдруг будет полезно.
Прошу прощения, что пишу комментарий, касающийся C++ в статью о проверке C#

Но есть такое ложное срабатывание:
The 'sr' pointer was utilized before it was verified against nullptr
Под использованием подразумевается вызов free(sr).

Стандарт чётко описывает, что free(nullptr) допустим и ничего не делает. Поэтому обычно я инициализирую переменные nullptr и делаю free независимо от того, выделялась ли под них память.

У меня это появилось на таком коде:
        SyncResult* sr = nullptr;
        for (;;) {
// ... skipped
                if (node == nullptr) {
                        free(sr);
                        return nullptr;
                }
// ... skipped
                if (sr == nullptr) {
                        sr = static_cast<SyncResult*>(malloc(...));
                } else {
                        append_to(sr, node);
                }
// ... skipped
                if (sr->count == 0) break;
        }
Да, это ложное срабатывание. Но пытаться его побороть не имеет смысла, так как это только может вредить искать другие ошибки. Например, быть может надо было сделать «free(sr2)» и анализатор тем самым помог найти опечатку. Да, для данного кода — это не так, но анализатор об этом догадаться не может.

Для исправления ситуации можно воспользоваться одним из механизмов подавления ложных срабатываний. Например, поставить комментарий //-V595 или использовать базу разметки.

Ещё один хороший вариант — переписать код. Неуместно смотрится malloc/free рядом с nullptr и static_cast. Быть может стоит перейти на умные указатели или вообще на vector.
Ещё один хороший вариант — переписать код.

Интересно, стандарт ведь так же разрешает delete nullptr, как оператор, не выполняющий никаких действий.
Я проверил — если поменять malloc/free на new/delete, ошибка исчезает.
Будьте последовательны ))

Неуместно смотрится malloc/free рядом с nullptr и static_cast.

SyncResult отдаётся наружу и по соглашениям внешний код делает ему free после использования. Эта ф-ция переписывалась и написана современно, всё остальное пока нет.
Я проверил — если поменять malloc/free на new/delete, ошибка исчезает. Будьте последовательны ))

Это недоработка с new/delete. Надо будет попробовать доработать.
Лучше попробовать доработать анализатор, чтобы в этой ситуации он смог построить какой-то инвариант цикла, показывающий что разыменовывания nullptr никогда не случится. Хотя это уже будет совсем новый уровень продукта.
Only those users with full accounts are able to leave comments. Log in, please.