Комментарии 20
>Судя по всему, в функциях со словом 'get' в имени ошибки допускаются чаще, чем в функциях с 'set'.
>Ну или, возможно, наш анализатор находит больше ошибок в функциях get, чем в функциях set
И первое и второе логически объяснимо — в функциях get нужно возвращать значение, а это чаще всего сложнее (начинаются проблемы с указателями и размерами памяти) чем просто обратиться за готовым переданным значением в функциях set
>Ну или, возможно, наш анализатор находит больше ошибок в функциях get, чем в функциях set
И первое и второе логически объяснимо — в функциях get нужно возвращать значение, а это чаще всего сложнее (начинаются проблемы с указателями и размерами памяти) чем просто обратиться за готовым переданным значением в функциях set
-1
На самом деле основная проблема этого исследования в том, что данные абсолютно не нормированы. В get-функциях 159 ошибок, хорошо, а сколько всего было get-функций в проанализированных проектах? Обычно get-функций существенно больше, чем set и после нормировки могла бы получиться совсем другая картина. Как я понимаю, для такой нормировки просто не сохранилось данных, а жаль. Так бы смотрелось серьёзнее (хоть и не было такой цели).
Кроме того, я не очень понял, брались ли сырые данные анализов или только то, что включили в онлайн-базу ошибок. Если второе, то по факту анализировали «интересные» ошибки, потому что, как я понимаю, в онлайн-базу вносят вручную.
Кроме того, я не очень понял, брались ли сырые данные анализов или только то, что включили в онлайн-базу ошибок. Если второе, то по факту анализировали «интересные» ошибки, потому что, как я понимаю, в онлайн-базу вносят вручную.
0
Ознакомился со статьёй про эффект последней строки. Интересно, а как вы это детектировали?
Просто потому, что правая часть дважды совпадает? По идее такой код мог бы быть правильным.
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.
Просто потому, что правая часть дважды совпадает? По идее такой код мог бы быть правильным.
0
Диагностика V525 неудачна так как часто даёт мусорные сообщения и из-за этого отнесена к 3 уровню. Но зато иногда она позволяет найти вот такие интересные места. В общих чертах, как работает эта диагностика, изложено в статье "Пояснения к статье про Copy-Paste".
+1
Не знал куда лучше написать, взгляните на этот ideone.com/FyWLki кусок кода. Там явно есть опечатка.
Я сегодня наткнулся на подобную ситуацию в одном из проектов и это было предупреждение Coverity «Missing break in switch». PVS молчит.
Думаю, на такие места и вам стоит обращать внимание.
Я сегодня наткнулся на подобную ситуацию в одном из проектов и это было предупреждение Coverity «Missing break in switch». PVS молчит.
Думаю, на такие места и вам стоит обращать внимание.
0
А как бездушный инструмент должен догадаться, что там не нужно проваливание? Coverity продолжает давать ту же ошибку, если в
default
изменить на a = 10
? Если да, то надо думать, что лучше: потенциально ложное срабатывание или вылавливание таких ошибок.0
Думаю, бездушному инструменту будет известно что в одном кейсе значение переменной меняется и потом после кейса происходит проваливание и в случае когда в следующем кейсе эта же переменная меняется, тут должно быть предупреждение. Для 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 ошибка чем ничего. Мое мнение.
На счет того, что будет выдавать если изменить на «а»… Не знаю, специфика 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 ошибка чем ничего. Мое мнение.
0
Да, это хороший пример. Стоит искать ситуацию, когда переменная может измениться дважды при определённом условии. Записали себе посмотреть и усовершенствовать соответствующую диагностику. А вот вообще ругаться на пропущенный break; очень плохая идея. Больше предупреждений не значит лучше. Полезное начинает теряться среди мусора.
0
«Вывод»: 'if' порождает ошибки.
Ага, а большинство ДТП происходят по вине трезвых водителей. Надо же соотносить количество примеров с ошибками, где встречается if, с количеством всех примеров, где встречается if.
Кстати, насчет заголовка статьи. Кто может сказать, какие инструменты понадобятся для измерения средней температуры пациентов больницы?
+1
Градусники
0
Счёты.
0
Мне кажется чаще всех встретиться var и символ ";"
-2
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Вычисление средней температуры по больнице