Comments 89
К сожалению, я знаю огромное количество разработчиков, которые допускают в своих проектах десятки, а иногда даже сотни варнингов. И я ничего не могу с этим поделать.
И как их проекты? Ими пользуются люди? Что говорят?
Некоторые в своих личных проектах такое допускают, некоторые работают и на работе так пишут. Некоторые лабы в универе так пишут. Особенно среди флешеров много такого народа. Я думаю отчасти поэтому флеш многие ругают. Даже в адобовских мануалах бывает код которые принебрегает типизацией и допускает варнинги.
Ну лабам и «личным» проектам такое простительно, ведь ими никто не пользуется.
А вот кстати еще на сайтах нередко сверху warning от php или еще кого-нибудь можно увидеть.
А вот кстати еще на сайтах нередко сверху warning от php или еще кого-нибудь можно увидеть.
Ну это вообще за гранью. Видел такие сайты… Такие варнинги даже в логах не должны допускаться, все следует исправлять) А отдавать на продакшне лог браузеру…
Если бы вы видели что товрится с сайтом, если включается полный репорт ошибок.
10/11 контента становится нотайсы и варнинги (только самописные сайты без cms и фреймворков).
Не понимаю, почему нельзя соблюдать простейшие правила и написать код без единой @ и нотайс ошибки.
10/11 контента становится нотайсы и варнинги (только самописные сайты без cms и фреймворков).
Не понимаю, почему нельзя соблюдать простейшие правила и написать код без единой @ и нотайс ошибки.
Попробуйте для развлечения скомпилировать SQLite3 — просто возьмите все исходники, добавьте их в проект и скомпилируйте. Предупреждений будут сотни, но никто же из-за этого не отказывается от использования SQLite.
к сожалению, такие проекты потом достаются еще и «в наследство». 300К строк кода, соответственно тысячи ворнингов, фиксить которые просто опускаются руки
допускают в своих проектах десятки, а иногда даже сотни варнингов
Не стоит забывать, что в отдельно взятых компиляторах отдельно взятые предупреждения сделаны настолько бездумно, что выдаются по поводу и без, и попытки доработать свой код напильником, чтобы они не выдавались, чаще приводят к ухудшению кода. Так что «допускает предупреждения в коде» — само по себе не провинность.
Я при этом не понимаю как этим можно пользоваться. А новые варнинги при разработке как учитывать? Сверять по количеству варнингов?
Я не буду за это агитировать, но один из способов — игнорировать все. По факту C++ дает кучу возможностей отстрелить себе ногу и все остальные части тела, которые никакие предупреждения компилятора выявить не помогут. Соответственно, логика у этого способа такая: в коде и так много что много где может сломаться, так что предупреждением больше, предупреждением меньше — на погоду не влияет. С виду работает — и ладно.
Как пользоваться? По сути — никак не пользоваться.
Как пользоваться? По сути — никак не пользоваться.
UFO just landed and posted this here
Проще решать запретом на компиляцию при наличии варнингов, естественно под основным компилятором, под который ведётся разработка. Правим код так чтобы их не было. Там где другие компайлеры варнинги выдают, нужно проверить и забить.
Не полетит. На первый взгляд, это мотивирует разработчиков делать так, чтобы «чертов компилятор не выдавал предупреждений», а на самом деле — это мотивирует их «сделать что угодно, чтобы руководство не доставало». Разработчики будут тупо глушить предупреждения или портить код, чтобы предупреждения не выдавались.
Заметьте, я не предлагаю игнорировать все предупреждения, я только привожу этот способ как один из реально используемых на практике.
Заметьте, я не предлагаю игнорировать все предупреждения, я только привожу этот способ как один из реально используемых на практике.
UFO just landed and posted this here
надо бы ставить больше скобок для ясности
Отличный пример.
С одной стороны, компилятор вроде как хочет помочь и предупреждает, что «вот тут вы может быть имели в виду что-то другое» и неплохо бы поставить скобки, чтобы было понятнее. С другой стороны, в сложном выражении добавление кучи скобок часто ухудшает понимание.
Почему так происходит? Потому что предупреждение плохо продумано. В большинстве случаев ситуация, когда «неплохо бы поставить скобки», сопровождается значительной сложностью выражения. Компилятору бы предложить расписать это выражение на несколько, а он выдает не особо полезное предупреждение. Пользователь глушит предупреждение, формально все в порядке, но однажды можно посадить ошибку в код.
А я за немного другой подход.
Warning'и можно отключить локально — только в том месте, где мы о нем знаем.
Итак, отключаем локально все ворнинги (да, работа еще та, но любой скриптовый язык в этом поможет), проверяем, что ничего не сломали (на всякий случай — код-то не менялся), а потом начинаем жизнь с чистого листа — не допускаем появления новых предупреждений и можем даже на радостях поменять настройки проекта — включить treat warnings as errors.
По мере рефакторинга отдельных частей можно будет возвращатсья к игнорированным предупреждениям и вычищать их «по правильному»
Warning'и можно отключить локально — только в том месте, где мы о нем знаем.
Итак, отключаем локально все ворнинги (да, работа еще та, но любой скриптовый язык в этом поможет), проверяем, что ничего не сломали (на всякий случай — код-то не менялся), а потом начинаем жизнь с чистого листа — не допускаем появления новых предупреждений и можем даже на радостях поменять настройки проекта — включить treat warnings as errors.
По мере рефакторинга отдельных частей можно будет возвращатсья к игнорированным предупреждениям и вычищать их «по правильному»
Картинка не грузится :(
«По всей видимости, прежняя заметка осталась незамеченной авторами Notepad++ и они не воспользовались PVS-Studio для проверки проекта.»
А что не позволило вам самим написать письмо?
А что не позволило вам самим написать письмо?
1gb.ru забыл продлить свой домен, и авторы Notepad++ не смотри активировать триальную версию PVS-Studio ;)
Спасибо, что задали актуальный вопрос.
Я пишу всем. Но если моё письмо попадает в спам или мой баг-репорт удаляют (а такое случалось), то мне всё равно. Если не уважительно относятся к людям, присылающих информацию, то почему я должен бегать за автором, чтобы «отдать фотографию»?
Я пишу всем. Но если моё письмо попадает в спам или мой баг-репорт удаляют (а такое случалось), то мне всё равно. Если не уважительно относятся к людям, присылающих информацию, то почему я должен бегать за автором, чтобы «отдать фотографию»?
А написать это нормально — не могли?
Вы просто не представляете насколько оригинальный вопрос (а вы писали авторам?) задали. Посмотрите историю публикаций на Хабре. В КАЖДОЙ статье находится желающий спросить это.
Учитывая манеру написания текста а тем более процитированного куска. Это совершенно нормальная реакция. Если бы в тексте было не высокомерное «По всей видимости, прежняя заметка осталась незамеченной авторами Notepad++ и они не воспользовались PVS-Studio для проверки проекта.» А текст из его ответа на мой вопрос " Но если моё письмо попадает в спам или мой баг-репорт удаляют (а такое случалось), то мне всё равно." Я бы и не спрашивал.
А мне вот без разницы, с высокомерием или нет мне указывают на ошибки. Ведь от этого ошибки не перестанут быть ошибками. Я просто беру и стараюсь все исправить. А оставлять ошибки только из за того, что вам не понравилось, как вам на них указали — это глупость, ведь пострадают в первую очередь ваши пользователи и вы сами. А тому, кто написал про ошибку может вообще наплевать будет.
Чего вы хотите от автора? Он написал заметку, написал письмо, написал вторую заметку. Все в чем он провинился — сделал безобидное замечание. Кто знает почему осталась незамеченной заметка? Может они ее и в глаза не видели? Может письмо потерялось?
Здесь нет никаких претензий, на мой взгляд.
Здесь нет никаких претензий, на мой взгляд.
Назрела проблема одинаковых вопросов, которая стала меня беспокоить. Отсюда и мои нездоровые ответы… Не знаю пока что делать с этим…
Высокомерие тут ни при чём. Я просто не хочу, делать из своих статей каку. Их читать тогда будет невозможно. Мне придется в каждую статью вставлять два листа одинакового текста, и делать заголовок — «Прежде чем хотите написать комментарий — прочтите это». :)
А внутри писать про то, сообщил ли я ошибки разработчикам, есть ли версия под Linux и почему её нет, почему PVS-Studio не работает на Visual Studio Express edition и еще несколько вопросов, которые обязательно задают каждый раз.
Высокомерие тут ни при чём. Я просто не хочу, делать из своих статей каку. Их читать тогда будет невозможно. Мне придется в каждую статью вставлять два листа одинакового текста, и делать заголовок — «Прежде чем хотите написать комментарий — прочтите это». :)
А внутри писать про то, сообщил ли я ошибки разработчикам, есть ли версия под Linux и почему её нет, почему PVS-Studio не работает на Visual Studio Express edition и еще несколько вопросов, которые обязательно задают каждый раз.
Написать «По всей видимости, прежняя заметка осталась незамеченной авторами Notepad++ и они не воспользовались PVS-Studio для проверки проекта а направленное им письмо они проригнорировали.»?
Disclaimer со ссылкой на страницу, где это все описывается, в начале каждой статьи. Только ссылка должна называться не «дисклеймер тут», а, к примеру, «наша позиция по вопросу баг-репортов» или что-то вроде.
Может быть и так, но… «Наша позиция по вопросу баг-репортов» — это не та ключевая информация, которую мы хотим донести до людей нашими статьями.
К тому же, как показывает опыт, ссылки не читают.
К тому же, как показывает опыт, ссылки не читают.
Простите, но кажется Вы мои статьи уже читали. Если так, то не понимаю, как можно зажать такой оригинальнейший вопрос. :)
мой баг-репорт удаляют (а такое случалось)
Почему удаляют? Считают спамом?
Без комментариев.
В смысле удаляют без комментариев :-).
В смысле удаляют без комментариев :-).
На ум приходит два варианта:
1. Из-за обилия ссылок на сами_знаете_что.
2. Жертвы проверки стыдятся своих ошибок.
1. Из-за обилия ссылок на сами_знаете_что.
2. Жертвы проверки стыдятся своих ошибок.
1. Из-за обилия ссылок на сами_знаете_что.
А как без ссылок? Как людям понять с помощью чего найдены ошибки?
обилия
Я был бы та-а-а-а-ак счастлив, если можно было бы один раз упомянуть PVS-Studio в статье и все. Но люди думают, что эти ошибки:
1. Найдены руками.
2. Найдены разными другими инструментами.
3. И даже не найдены вообще :-).
что приходится упоминать чаще. Особенность человеческой психики видимо.
1. Найдены руками.
2. Найдены разными другими инструментами.
3. И даже не найдены вообще :-).
что приходится упоминать чаще. Особенность человеческой психики видимо.
В статье — нормально, а в письме или багрепорте наверно хватит и одного упоминания.
В этой ветке комментариев показан очень хороший пример человеческой невнимательности. А Вы говорите один раз упомянуть и все.
даже не найдены вообще
Любопытно, о чем здесь речь.
А может ещё проще. Например, попадаем в спам из-за anal (code analyzer). Давно чешутся руки помучить парочку писателей антиспамовских поделок. Количества вреда от них равно количеству вреда от самого спама.
Ещё вспоминается случай, когда из-за лошади, публикация статьи на одном сайте была автоматически отклонена. Ну конечно, если «horse», то это значит про секс будет… Тьфу…
Ещё вспоминается случай, когда из-за лошади, публикация статьи на одном сайте была автоматически отклонена. Ну конечно, если «horse», то это значит про секс будет… Тьфу…
Вам пора давно составить мини FAQ для хабра, с заготовленными ответами на такие вопросы, и вставлять в конец статьи, чтобы каждый раз заново не отвечать :)
Спасибо за статью, остался только один вопрос. Статическим анализатором PVS-Studio нужно пользоваться регулярно?
Можно как угодно, но наибольшую пользу приносить постоянное её использование.
Смысл статического анализа примерно в следующем: не знающая усталости программа может перепахать тонны кода и очень надежно найти там некоторые закономерности, возможно, указывающие на наличие ошибки.
Если ее сообщения достаточно часто содержат действительно полезные предупреждения, вы получаете бонус от использования — программа ловит вас за руку при каждой проверке, в результате внесенные в код проблемы не просачиваются даже в репозиторий.
Тогда логично, чтобы анализ выполнялся после каждой правки (PVS-Studio это делает в режиме инкрементального анализа). Это при условии, что шума не слишком много, иначе вы тратите время на разбирательство — проблема там или нет и только замусориваете код вставками для подавления предупреждения.
Если ее сообщения достаточно часто содержат действительно полезные предупреждения, вы получаете бонус от использования — программа ловит вас за руку при каждой проверке, в результате внесенные в код проблемы не просачиваются даже в репозиторий.
Тогда логично, чтобы анализ выполнялся после каждой правки (PVS-Studio это делает в режиме инкрементального анализа). Это при условии, что шума не слишком много, иначе вы тратите время на разбирательство — проблема там или нет и только замусориваете код вставками для подавления предупреждения.
Про инкрементальный анализ.
Две задачи, которые решаются с помощью инкрементального анализа:
1. Автоматизация запуска анализатора сразу же после компиляции на машине разработчика.
2. Получение выгоды от внедрения статического анализа в большом проекте БЕЗ необходимости проверки всего проекта. Фактически вы можете начать внедрять статический анализ кода, проверяя только тот код (те файлы), который модифицируется разработчиками в настоящее время и не лезть в кучу старых файлов, которые не модифицируются
Две задачи, которые решаются с помощью инкрементального анализа:
1. Автоматизация запуска анализатора сразу же после компиляции на машине разработчика.
2. Получение выгоды от внедрения статического анализа в большом проекте БЕЗ необходимости проверки всего проекта. Фактически вы можете начать внедрять статический анализ кода, проверяя только тот код (те файлы), который модифицируется разработчиками в настоящее время и не лезть в кучу старых файлов, которые не модифицируются
Исправлять ошибки в (развивающейся) программе нужно регулярно? Или достаточно один раз исправить все ошибки, а потом просто продолжать писать новый код без ошибок? Ответьте для себя на эти вопросы — от этого и зависит «регулярность приема» PVS-Studio.
А я все думал, что будет когда закончатся известные открытые проекты :)
Вон оно как оказалось, по второму кругу пошли!
Вон оно как оказалось, по второму кругу пошли!
Кстати давно интересно, почему лицензия минимум на 5 разработчиков.
Или просто продавать дешевле 3500 eur вам не интересно?
Или просто продавать дешевле 3500 eur вам не интересно?
Статический анализатор рационален в средних и крупных проектах. Там где над проектом трудится 1-2 человека, применять статический анализ конечно тоже полезно, но не так. Причем, индивидуальные разработчики называют ожидаемой ценой 100$-200$. Это понятно. Для их маленьких проектов платить больше за инструмент не первой необходимости, смысла нет. Но и нам нет смысла сопровождать 3500/(200*1.3) = 23 разработчика, вместо одной командой лицензии. Суеты много, денег мало. В сфере статического анализа поддержка стоит дорого и с 100-200$ можно запросто уйти в минус. Вариант «продовать без поддержки» мы не рассматриваем.
Другая причина — люди хитрят. Покупают одиночную лицензию, ведь он будет пользоваться «один». И при этом «как-то забывает», что проект пишет целая команда. Или просто он действительно на поддержке проекта сейчас один, но потрачено на этот проект было до этого многие человеко-годы. Зачем нам это? Раз проект создавала/создает команда, то и платить надо за команду.
Другая причина — люди хитрят. Покупают одиночную лицензию, ведь он будет пользоваться «один». И при этом «как-то забывает», что проект пишет целая команда. Или просто он действительно на поддержке проекта сейчас один, но потрачено на этот проект было до этого многие человеко-годы. Зачем нам это? Раз проект создавала/создает команда, то и платить надо за команду.
Скажите, а Вы не пробовали сравнивать результаты, получаемые с помощью PVS-Studio с результатами, выдаваевыми такими программами как Frama-C и VCC (Verified C Compiler)?
Нет. А из каких соображений интересуетесь?
Ну это довольно известные статические верификаторы для Си-кода, второй даже имеет отличную интеграцию с Visual Studio. Плюс я довольно неплохо знаю что они имеют и как они это делают. В их публикациях есть много сравнений между собой и с разными другими программами, но я никогда даже не слышал упоминания о Вашей разработке — поэтому мне стало интересно, может быть Вы делали какие-то сравнения.
Я бы еще и про PeX спросил (у него тоже есть статическая верификация) — но увидел, что Ваш тул не работет с managed code, и не стал. А так было бы тоже интересно сравнить.
Я бы еще и про PeX спросил (у него тоже есть статическая верификация) — но увидел, что Ваш тул не работет с managed code, и не стал. А так было бы тоже интересно сравнить.
Хорошо пинать такие проекты, как Notepad++. Его автор вам скорее всего не ответит. Он ни разу не претендует на то, чтобы проект служил идеалом чистого и качественного кода. Да и не требуется это в таком проекте, по большому счету.
Если бы вы находили и показывали ошибки в проектах, на которые тратятся сотни человеко-часов тестирования и ревью, ошибки, которые могут стоить очень дорого (к примеру уязвимости), это бы гораздо убедительнее демонстрировало пользу от вашего продукта.
Если бы вы находили и показывали ошибки в проектах, на которые тратятся сотни человеко-часов тестирования и ревью, ошибки, которые могут стоить очень дорого (к примеру уязвимости), это бы гораздо убедительнее демонстрировало пользу от вашего продукта.
Почитайте наши статьи про Chromium, Clang, Qt и т.п. Список здесь (http://www.viva64.com/ru/pvs-studio/) внизу страницы.
ошибки, которые могут стоить очень дорого (к примеру уязвимости)
Не понимаю этой логики. Почему-то уязвимость — это сразу серьезная проблема, а если, скажем текст, в редакторе иногда искажается (это я привел гипотетический пример проблемы, которая в принципе могла бы быть в Notepad++), и это мешает работать, то это уже как будто и не проблема. Нашли уязвимость — хорошо, нашли какой-нибудь мелкий дефект в редакторе, из-за которого не так прыгает каретка, — тоже хорошо.
Кстати, Вы можете высказать предложения, что было-бы интересно проверить. Мы будем рады, если Вы напишите нам (прочитав в начале это :-).
Nginx.
Вы прочитали?
как насчет варнингвара: vim VS np++ )))
Каждый раз читая ваши статьи я удивляюсь — как оно ( исследуемый проект ) вообще работает?
хотя notepad++ у меня ни разу не падал и не глючил
хотя notepad++ у меня ни разу не падал и не глючил
Очень просто.
Во-первых, все заметные и важные ошибки обычно вылавливают другими способами. Программа падает — отладили, исправили. На такие обзоры остаются те ошибки, которые не проявились достаточно ярко, чтобы их начали искать.
Во-вторых, оставшиеся ошибки вообще не обязаны очевидно проявляться. Где-то на вход подаются только такие данные, при которых ошибка не проявляется. Где-то ошибка проявляется, но код вызывается крайне редко. В итоге ошибок, которые хотя бы как-то заметно проявляются при реальной работе, очень мало.
Это такая ирония — вроде бы статический анализ много чего нашел и должен дать улучшение качества кода, а по факту измерить это улучшение совсем не просто.
Во-первых, все заметные и важные ошибки обычно вылавливают другими способами. Программа падает — отладили, исправили. На такие обзоры остаются те ошибки, которые не проявились достаточно ярко, чтобы их начали искать.
Во-вторых, оставшиеся ошибки вообще не обязаны очевидно проявляться. Где-то на вход подаются только такие данные, при которых ошибка не проявляется. Где-то ошибка проявляется, но код вызывается крайне редко. В итоге ошибок, которые хотя бы как-то заметно проявляются при реальной работе, очень мало.
Это такая ирония — вроде бы статический анализ много чего нашел и должен дать улучшение качества кода, а по факту измерить это улучшение совсем не просто.
Это такая ирония — вроде бы статический анализ много чего нашел и должен дать улучшение качества кода, а по факту измерить это улучшение совсем не просто.
Статический анализ нужен тогда, когда у разработчиков возникает вопрос: «А что ЕЩЕ я могу сделать для того, чтобы код был лучше?».
При этом не надо забывать, что многие разработчики до этого состояния не доходят никогда. Хотя бы потому что качество кода — что-то эфемерное и занудное, а попробовать новый фреймворк или прикрутить новые фичи очень хочется.
Не стоит забывать, что статический анализ позволяет быстро найти то, что относится к «во-первых». Зачем тратить силы на отладку и тем более на отрытие бага в отделе тестирования, если часть из них можно выловить моментаьно. Это очень важный момент, который постоянно упускают из виду.
Sign up to leave a comment.
Повторная проверка проекта Notepad++