Комментарии 19
А вы могли бы сделать сравнение количества ошибок для Mono, CoreCLR и Rolsyn? Например в измерении количество серьезных багов на строки кода.
Примерно в виде:
Проект | строк кода | найдено багов | багов на 1000 строк
UPD. Хотя конечно было бы еще интересней посмотреть на все проверенные проекты в сравнении
Примерно в виде:
Проект | строк кода | найдено багов | багов на 1000 строк
UPD. Хотя конечно было бы еще интересней посмотреть на все проверенные проекты в сравнении
+1
Проверяете ли вы код PVS-Studio при помощи PVS-Studio?
-9
Уже неоднократно задавали этот вопрос. Поэтому его даже в FAQ вынесли.
+3
После Resharper ваш анализатор у нас ничего не нашел. Я сначала думал что не работает — сделал пару описок — обнаружил.
Пока тщательно наблюдаю за проектом. Если будет находить то что не находит Resharper — придется использовать, конечно. Ошибки дорого стоят.
Пока тщательно наблюдаю за проектом. Если будет находить то что не находит Resharper — придется использовать, конечно. Ошибки дорого стоят.
+2
У решарпера и пвс-студио немного разный подход к обнаружению ошибок, поэтому рано или поздно расхождения появятся =)
Решарпер ищет ошибки здесь и сейчас, по мере того, как вы просматриваете / редактируете / пишете новый код. Анализы работают локально и быстро (по крайней мере должны работать быстро).
Пвс-студио работает в другом режиме — она получает на вход уже написанный проект, дальше шуршит некоторое время и выдает сразу список ошибок по всему проекту. Подозреваю (хотя и не знаю наверняка) что их анализы отвечают другим требованиям, нежели наши =)
Решарпер ищет ошибки здесь и сейчас, по мере того, как вы просматриваете / редактируете / пишете новый код. Анализы работают локально и быстро (по крайней мере должны работать быстро).
Пвс-студио работает в другом режиме — она получает на вход уже написанный проект, дальше шуршит некоторое время и выдает сразу список ошибок по всему проекту. Подозреваю (хотя и не знаю наверняка) что их анализы отвечают другим требованиям, нежели наши =)
+2
Ага, работает в фоне и потом выводит сообщение что нашла проблемы в самый неподходящий момент :). Решарпер действует правильнее — сообщает о сомнительном коде сразу как его написали, те сокращает время существования ошибки до 0.
0
НЛО прилетело и опубликовало эту надпись здесь
Небольшая поправка по поводу использования MonoDevelop в Unity3D.
С версии 5.3 в Unity используется MonoDevelop версий 5.x.
За информацию спасибо Lertmind.
С версии 5.3 в Unity используется MonoDevelop версий 5.x.
За информацию спасибо Lertmind.
0
Не знаю, почему, но как только вы стали писать про версию PVS Studio для C#, я лично перестал вас читать. Потерялся интерес. Может, просто совпадение. Это не претензия — просто обратная связь; вдруг будет полезно.
-3
Прошу прощения, что пишу комментарий, касающийся 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;
}
0
Да, это ложное срабатывание. Но пытаться его побороть не имеет смысла, так как это только может вредить искать другие ошибки. Например, быть может надо было сделать «free(sr2)» и анализатор тем самым помог найти опечатку. Да, для данного кода — это не так, но анализатор об этом догадаться не может.
Для исправления ситуации можно воспользоваться одним из механизмов подавления ложных срабатываний. Например, поставить комментарий //-V595 или использовать базу разметки.
Ещё один хороший вариант — переписать код. Неуместно смотрится malloc/free рядом с nullptr и static_cast. Быть может стоит перейти на умные указатели или вообще на vector.
Для исправления ситуации можно воспользоваться одним из механизмов подавления ложных срабатываний. Например, поставить комментарий //-V595 или использовать базу разметки.
Ещё один хороший вариант — переписать код. Неуместно смотрится malloc/free рядом с nullptr и static_cast. Быть может стоит перейти на умные указатели или вообще на vector.
+1
Ещё один хороший вариант — переписать код.
Интересно, стандарт ведь так же разрешает
delete nullptr
, как оператор, не выполняющий никаких действий.Я проверил — если поменять malloc/free на new/delete, ошибка исчезает.
Будьте последовательны ))
Неуместно смотрится malloc/free рядом с nullptr и static_cast.
SyncResult
отдаётся наружу и по соглашениям внешний код делает ему free
после использования. Эта ф-ция переписывалась и написана современно, всё остальное пока нет.0
Я проверил — если поменять malloc/free на new/delete, ошибка исчезает. Будьте последовательны ))
Это недоработка с new/delete. Надо будет попробовать доработать.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ищем ошибки в MonoDevelop