Как стать автором
Обновить

Комментарии 20

>Судя по всему, в функциях со словом 'get' в имени ошибки допускаются чаще, чем в функциях с 'set'.
>Ну или, возможно, наш анализатор находит больше ошибок в функциях get, чем в функциях set

И первое и второе логически объяснимо — в функциях get нужно возвращать значение, а это чаще всего сложнее (начинаются проблемы с указателями и размерами памяти) чем просто обратиться за готовым переданным значением в функциях set
На самом деле основная проблема этого исследования в том, что данные абсолютно не нормированы. В get-функциях 159 ошибок, хорошо, а сколько всего было get-функций в проанализированных проектах? Обычно get-функций существенно больше, чем set и после нормировки могла бы получиться совсем другая картина. Как я понимаю, для такой нормировки просто не сохранилось данных, а жаль. Так бы смотрелось серьёзнее (хоть и не было такой цели).

Кроме того, я не очень понял, брались ли сырые данные анализов или только то, что включили в онлайн-базу ошибок. Если второе, то по факту анализировали «интересные» ошибки, потому что, как я понимаю, в онлайн-базу вносят вручную.
Брались данные, включённые в онлайн-базу ошибок.
Я думаю, у вас немало сырых данных. Наверняка вы каждую ночь гоняете автоматом PVS-Studio на десятках проектов. Взяли бы оттуда, там же и нормировать проще.
Ознакомился со статьёй про эффект последней строки. Интересно, а как вы это детектировали?

SlimDX

for( int i = 0; i < 2; i++ )
{
  sliders[i] = joystate.rglSlider[i];
  asliders[i] = joystate.rglASlider[i];
  vsliders[i] = joystate.rglVSlider[i];
  fsliders[i] = joystate.rglVSlider[i];
}

В последней строке надо было использовать массив rglFSlider.

Просто потому, что правая часть дважды совпадает? По идее такой код мог бы быть правильным.
Диагностика V525 неудачна так как часто даёт мусорные сообщения и из-за этого отнесена к 3 уровню. Но зато иногда она позволяет найти вот такие интересные места. В общих чертах, как работает эта диагностика, изложено в статье "Пояснения к статье про Copy-Paste".
Не знал куда лучше написать, взгляните на этот ideone.com/FyWLki кусок кода. Там явно есть опечатка.
Я сегодня наткнулся на подобную ситуацию в одном из проектов и это было предупреждение Coverity «Missing break in switch». PVS молчит.
Думаю, на такие места и вам стоит обращать внимание.
А как бездушный инструмент должен догадаться, что там не нужно проваливание? Coverity продолжает давать ту же ошибку, если в default изменить на a = 10? Если да, то надо думать, что лучше: потенциально ложное срабатывание или вылавливание таких ошибок.
Думаю, бездушному инструменту будет известно что в одном кейсе значение переменной меняется и потом после кейса происходит проваливание и в случае когда в следующем кейсе эта же переменная меняется, тут должно быть предупреждение. Для pvs это должно быть раз плюнуть, особенно после их семантических анализах текста и соответствии ему названий переменных…

На счет того, что будет выдавать если изменить на «а»… Не знаю, специфика Coverity в том что просто так не проверишь им, это как сервис предоставляемый только с их сервера.

Пролистал список предупреждений… нашел только два касающиеся «switch»:
www.viva64.com/ru/d/0177/
www.viva64.com/ru/d/0239/

Например cppcheck свежий вообще примитивно на эту ситуацию смотрит и предупреждает только в случае когда явно:
switch (a) {
case 1: b = 1; break;
case 2:
b = 2;
default: b = 10;
}

Пусть лучше уж будет 10 ложных и 1 ошибка чем ничего. Мое мнение.
Да, это хороший пример. Стоит искать ситуацию, когда переменная может измениться дважды при определённом условии. Записали себе посмотреть и усовершенствовать соответствующую диагностику. А вот вообще ругаться на пропущенный break; очень плохая идея. Больше предупреждений не значит лучше. Полезное начинает теряться среди мусора.
«Вывод»: 'if' порождает ошибки.

Ага, а большинство ДТП происходят по вине трезвых водителей. Надо же соотносить количество примеров с ошибками, где встречается if, с количеством всех примеров, где встречается if.

Кстати, насчет заголовка статьи. Кто может сказать, какие инструменты понадобятся для измерения средней температуры пациентов больницы?
Градусники
Этого недостаточно.
А вы много градусников возьмите.

Почему недостаточно?
Надо учесть физический смысл температуры. Тогда станет понятно, что в первом приближении нужны термометр и весы, а для повышения точности еще и калориметр.
Счёты.
Стоило указать, что проблема скорее физическая чем вычислительная. Ответ см. выше.
Мне кажется чаще всех встретиться var и символ ";"
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий