Pull to refresh

Comments 33

Спасибо за идею — «Incremental Analysis after Build».
Мы к сожалению на С++ не пишем, но интересно попробовать настроить эту возможность на нашем билд сервере.
ой-ой-ой

Текст на всплывающем окошке — крайне плохой.

«1 error in your source code»

что мы видим?
— прямое гнобление человека. _твой_ код — говно. это недопустимо само по себе.
— полстатьи посвящено ложным срабатываниям. почему тогда error?
— error(s) — вы серьёзно? что, правда? не посчитать одна или несколько? сейчас точно 2011 год?

Когда я работал в одной крупной компании, у нас были чёткие правила поведения на code-review:
— анализируется код и только код
— категорически запрещены (под страхом увольнения) какие-либо персональные оценки вида: «что за дебил это писал?», «бред какой-то», «руки бы поотрывал»

Я бы переделал на что-нибудь приличнее:

One possible error found
— Recently compiled code may introduce 1 possible error. Click here to get details.

А ещё лучше, если ошибка ровно одна — просто показать её!

One possible error found
— Recently compiled code may be affected by stack overflow error in buffer.cpp.
Click here to get details.

Ну и вообще, не пожалейте денег и наймите английского native-speaker'а проверить дух и лексику во всех сообщениях.
>> Текст на всплывающем окошке — крайне плохой.

Большое спасибо за взгляд со стороны. Обязательно учтем это.

Вообще можно, если есть вероятность ошибочного срабатывания, писать вместо 'error', 'suspicious code' или что-нибудь подобное.
«Текст на всплывающем окошке — крайне плохой.»
что мы видим?
— прямое гнобление человека. _твой_ текст в UI — говно.

«1 error» по-моему не так гнобил. =)
kosiakk на личном примере показал, как НЕ надо писать сообщения. И был прав.
>что мы видим? — прямое гнобление человека. _твой_ текст в UI — говно.

Уж не знаю, что там видите вы, но мы ничего подобного мы там не видим. Мы видим оценку текста («текст — крайне плохой»), но не оценку человека («вы написали крайне плохой текст»).
"Твой текст" — это вы додумали сами.
Соглашусь, параллель получилась не очень тонкой. Но все же, «1 error» — это не такое уж и «гнобление».
«Гнобление» не в «1 error», а в «in your source code».
Моя претензия к «1 error» в том, что это может оказаться ложным срабатыванием (по признанию самого автора), но сообщается об этом, как об однозначной катастрофе.
За два года можно было сделать интеграция в «bug tracking systems», системы контроля версий и централизованный «build environment».

Непонятно как работать с вашим продуктам тестерам/QA. В некоторых компаниях есть тестеры. Они ищут приоритетных дефекты, назначают приоритеты и риски. И только после оценки влияния дефекта на бизнес, программисты начинают исправят ошибку.
>> За два года можно было сделать интеграция в «bug tracking systems».

Никто не просил пока, а выплевывать весь отчет в баг-треккер — явный спам и мусор.

>> системы контроля версий

есть конечно же

>> централизованный «build environment».

с этим тоже никаких проблем.

>> Непонятно как работать с вашим продуктам тестерам/QA.

Статический анализ кода — это инструмент для программиста. Точно также и про отладчик можно сказать: «Не понятно как с ним работать тестерам/QA».
>Никто не просил пока, а выплевывать весь отчет в баг-треккер — явный спам и мусор.
После проверки и назначение приоритета, можно автоматики импортировать.
>Статический анализ кода — это инструмент для программиста.
Вашим анализатором кода, могут пользоваться только программисты. Я работал в компании, где только тестеры пользовались статическим анализатором кода. Это очень полезно, для программиста. Им не нужно отсеивать мусор, а работа над тикетами приучает не допускать аналогичные повторные ошибки.
Расскажите, пожалуйста, подробнее — как тестеры могут пользоваться статическим анализатором? Я не очень представляю это. Или тестеры — программисты?

И скажите название анализатора, которым они пользовались.
coverity prevent, наверно сейчас это Coverity Static Analysis.

Каждое утро или по заданию, тестеры классифицировали все дефекты. Дальше программисты работали с тикетами.
Бывают кстати и программисты, но это наверное в единичных компаниях. В Parallels например большая часть QA отдела программисты, даже и реверсеры есть, которые в случае чего могут и код сторонних приложений глянуть, ну или автоматизировать что-то изнутри.
Есть ещё компании где тестеры пишут код (на java в конкретном случае) =)
Если имеются в виду внешние тестеры, то они могут ВООБЩЕ не знать и не понимать программный код. В этом случае дать им анализатор кода — равносильно одному из двух: либо все предупреждения трансформируются в ошибки, либо на него просто забьют.
>Теперь анализатор запускается сразу после компиляции и проверяет только те файлы, которые были «задеты» правками пользователя.

тогда может стоит подумать, о плагине к системам контроля версий, например проверка кода при коммите в меркуриале «pre-commit hook», которая будет проверять измененные файлы или вообще дифы и не давать делать коммит.
Просто разработчики часто, билд жмут после нескольких строчек изменений, еще не закончив реализацию фичи, и ошибки от вашего анализатора на неготовом коде могут раздражать.
Давно читаю посты про PVS-Studio и радуюсь, какая классная штука!

А есть что-нибудь подобное для PHP?
А можно где нить почитать, про внутренности PVS? Например как вы код код анализируете — методов достаточно много.
Как набираете список правил?

ЗЫ Кстати на вашем сайте достаточно интересный набор правил живет — странно, что вы про него рассказываете. www.viva64.com/ru/d/
Кстати, я правильно понимаю, что PVS частично основана на OpenC++?
Да. PVS-Studio основана на нашей же VivaCore, которая в свою очередь основана на OpenC++. Но чуть-ли не весь код OpenC++ уже переписан. Как минимум мы добавили: поддержку C, поддержку C++0x, поддержку Visual Studio ну и много чего еще.
>> А можно где нить почитать, про внутренности PVS?

Пока нет, но у нас уже есть в планах статья про это.

>> Как набираете список правил?

Придумываем сами и подсказывают пользователи. Стараемся не копировать тупо чужие правила, так как многие из них устарели и не актуальны. Вообще мы стараемся делать современные правила, оставляя за бортом тот баласт, который некоторые анализаторы тянут из 80-х годов.

>> Кстати на вашем сайте достаточно интересный набор правил живет — странно, что вы про него рассказываете.

Подскажите, пожалуйста, каким образом про него рассказать так, чтобы это было интересно? Ведь просто «вот тут у нас больше сотни правил» — это же скучновато.
Думаю взять пяток с самой интересной историей создания. Например, появишиеся в результате поиска реальных ошибок.
Тем более, многие правила очень всеобъемлющи и могут покрывать с десяток различных случаев. Не только указанные в примерах.
false positives надо методично уничтожать. Сделайте сервис который принимает все отвергнутые срабатывания, у вас будет накапливаться статистика и опыт по ошибкам, если ошибка на самом деле присутствует можно отправить пользователю обратный ответ. чтобы он ее исправил (по сути интерактивный support). Это можно объединить в подобие форума, вики и faq — тогда и другие пользователи смогут участвовать в обсуждении чужих ошибок и принятии правильного решения, генерации набора правил работы с подобным кодом. В продолжении интерактивного support'а пользователь может получать обновления из соответствующей темы в виде RSS или еще чего. Посмотрите в сторону формирования практик безопасной, быстрой, безошибочной разработки на C++. Начните с простых примеров типа banned.h как в SDL или нескольких примеров работы с массивами, указателями (это есть во многих книгах, но чаще короткий емкий и выверенный кусок кода лучше любых талмудов). Смысл в том чтобы сформировать community которое будет заходить на сайт с целью прокачивания скиллов C++, а это и реклама, и feedback, и crowdsourcing.
UFO just landed and posted this here
UFO just landed and posted this here
Ещё лучше: PVS-Studio hasn't found errors. :)
Еще лучше: PVS-Studio correts all found errors. :)
Sign up to leave a comment.

Articles