Ищем ошибки в MonoDevelop

[Ogoun]

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

UPD. Хотя конечно было бы еще интересней посмотреть на все проверенные проекты в сравнении

[Andrey2008]

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

[DIMOSUS]

Проверяете ли вы код PVS-Studio при помощи PVS-Studio?

[redmanmale]

Уже неоднократно задавали этот вопрос. Поэтому его даже в FAQ вынесли.

[codecity]

После Resharper ваш анализатор у нас ничего не нашел. Я сначала думал что не работает — сделал пару описок — обнаружил.

Пока тщательно наблюдаю за проектом. Если будет находить то что не находит Resharper — придется использовать, конечно. Ошибки дорого стоят.

[DragonFire]

У решарпера и пвс-студио немного разный подход к обнаружению ошибок, поэтому рано или поздно расхождения появятся =)
Решарпер ищет ошибки здесь и сейчас, по мере того, как вы просматриваете / редактируете / пишете новый код. Анализы работают локально и быстро (по крайней мере должны работать быстро).
Пвс-студио работает в другом режиме — она получает на вход уже написанный проект, дальше шуршит некоторое время и выдает сразу список ошибок по всему проекту. Подозреваю (хотя и не знаю наверняка) что их анализы отвечают другим требованиям, нежели наши =)

[xtraroman]

Ага, работает в фоне и потом выводит сообщение что нашла проблемы в самый неподходящий момент :). Решарпер действует правильнее — сообщает о сомнительном коде сразу как его написали, те сокращает время существования ошибки до 0.

[Andrey2008]

Не все диагностики можно выполнить сразу, как только написана очередная строчка. Всё-таки полноценный статический анализ и подсветка подозрительных мест на лету — это разные вещи.

[DragonFire]

Именно об этом я и пытался написать… тут нету правильного и не правильного, просто разные подходы и разные анализы

[poxvuibr]

Ну может и заставляют. Но vim режим всё равно как отвалился, так и не работает.

[poxvuibr]

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

[SergVasiliev]

Небольшая поправка по поводу использования MonoDevelop в Unity3D.
С версии 5.3 в Unity используется MonoDevelop версий 5.x.
За информацию спасибо Lertmind.

[DmitryKoterov]

Не знаю, почему, но как только вы стали писать про версию PVS Studio для C#, я лично перестал вас читать. Потерялся интерес. Может, просто совпадение. Это не претензия — просто обратная связь; вдруг будет полезно.

[qw1]

Прошу прощения, что пишу комментарий, касающийся 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;
        }

[Andrey2008]

Да, это ложное срабатывание. Но пытаться его побороть не имеет смысла, так как это только может вредить искать другие ошибки. Например, быть может надо было сделать «free(sr2)» и анализатор тем самым помог найти опечатку. Да, для данного кода — это не так, но анализатор об этом догадаться не может.

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

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

[qw1]

Ещё один хороший вариант — переписать код.

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

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

SyncResult отдаётся наружу и по соглашениям внешний код делает ему free после использования. Эта ф-ция переписывалась и написана современно, всё остальное пока нет.

[Andrey2008]

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

Это недоработка с new/delete. Надо будет попробовать доработать.

[qw1]

Лучше попробовать доработать анализатор, чтобы в этой ситуации он смог построить какой-то инвариант цикла, показывающий что разыменовывания nullptr никогда не случится. Хотя это уже будет совсем новый уровень продукта.