Comments 159
По моему опыту, те программисты которые не любят статический анализатор в основном банально редко его запускают из-за чего возникает множество ложных срабатываний.
Есть еще такие, которые не любят, хотя и ни разу не запускали :-).
Так оно и есть. К сожалению, для индустрии, многие никак не могут осознать, что вывод анализатора нужно держать чистым. А ведь это уже давно описано, разобрано и обсуждено для предупреждений компилятора. Когда накапливаются предупреждения компилятора, люди перестают их читать, они перестают помогать, а только мешают. Именно отсюда растут ноги у ключей компилятора, заставляющих интерпретировать предупреждения как ошибки.
Но воз и ныне там. Мы проверяем много проектов и видим, что при компиляции многие проекты страдают «недержанием предупреждений». При компиляции выводятся сотни warnings.
Собственно, та же самая картина и с анализаторами кода. И, опять-таки к сожалению, часто только менеджер может изменить ситуацию. Используя административные рычаги, он может заставить не оставлять варнинги и внедрять анализаторы. Вот так и живём.
Но воз и ныне там. Мы проверяем много проектов и видим, что при компиляции многие проекты страдают «недержанием предупреждений». При компиляции выводятся сотни warnings.
Собственно, та же самая картина и с анализаторами кода. И, опять-таки к сожалению, часто только менеджер может изменить ситуацию. Используя административные рычаги, он может заставить не оставлять варнинги и внедрять анализаторы. Вот так и живём.
Собственно, та же самая картина и с анализаторами кода. И, опять-таки к сожалению, часто только менеджер может изменить ситуацию.
Обычно как раз менеджер и является причиной
Но воз и ныне там. Мы проверяем много проектов и видим, что при компиляции многие проекты страдают «недержанием предупреждений». При компиляции выводятся сотни warnings.
А что в этой статье может не понравиться программистам?
Мне вот тоже непонятно. Если есть инструмент, который за тебя прошерстит код и укажет на подозрительные или очевидно ошибочные места, это же круто. Конечно, искать и исправлять ошибки бывает интересно, но если программист не нашёл их сразу, видимо, они неочевидные или редко срабатывающие, что повышает их опасность в разы. А не ошибается, как известно, только тот, кто ничего не делает.
Странно, что среди разработчиков есть такие самоуверенные люди, которые думают, что пишут идеальный код. Они вообще ни одной популярной большой программой не пользовались, что ли? Везде полно багов и дыр, и в ОС, и в браузерах, и в прочем прикладном софте. Считать себя на голову круче всех тех, кто пишет операционки и браузеры, могут разве что совсем неопытные программисты. Ну и эффект Даннинга-Крюгера забывать не стоит. Я вот свой уровень оценил бы как средний или ниже среднего, и чем больше узнаю, тем ниже этот уровень оцениваю.
Странно, что среди разработчиков есть такие самоуверенные люди, которые думают, что пишут идеальный код.
Добро пожаловать в реальный мир программирования. :) Думаю, дискуссия которая разворачивается, будет Вам необычно и интересна.
UFO just landed and posted this here
Ну а какая практическая польза в такой задаче на собеседовании?
UFO just landed and posted this here
На практике же — 90% из тех, кто помнит метод пузырька, его и будут использовать при необходимости написать сортировку. Прикола ради задали вопрос по пузырьку студенту стажеру. Нарисовал правильно. А он, на минуточку, человек, который пишет код уровня:
if (x === true) {
toggle(true);
} else if (x === false) {
toggle(false);
}
Они почему-то уверены, что статический анализатор неприятен всем программистам:
Мы поговорим о вещах, которые неприятны программистам.
Наша компания занимается разработкой анализатора PVS-Studio, предназначенного для поиска ошибок в коде программ на языке C, C++ и C#. Идея проста: запускаем регулярно анализатор и изучаем участки кода, которые показались ему подозрительными. В общем, некий аналог автоматического code-review.
Это называется гипербола (стилистическая фигура явного и намеренного преувеличения, с целью усиления выразительности и подчёркивания сказанной мысли). Конечно не всем, но мы видим что это действительно есть, и даже в обсуждении этой статьи. Поэтому и захотелось обратить внимание на этой читателей. И мне кажется, это удалось и завязывается интересная дискуссия.
UFO just landed and posted this here
Я за C++ скажу. По моему субъективному мнение (а в этом вопросе мне можно доверять), разницы между качеством кода C и C++ нет. И там, и там есть опечатки и и.д. Да, в C++ стало лучше с управлением памяти, зато и способов накосить стало больше. Например, можно написать std::unique_ptr p(new A[3]);. Т.е. выделяем массив, а уничтожаем потом как один элемент.
Иногда попадаются очень качественные C++ проекты, написанные на всяких контейнерах, с применением всяких хороших техник и т.п. И там очень сложно найти ошибку (пример). Но так ведь есть и очень качественные C проекты (пример).
Иногда попадаются очень качественные C++ проекты, написанные на всяких контейнерах, с применением всяких хороших техник и т.п. И там очень сложно найти ошибку (пример). Но так ведь есть и очень качественные C проекты (пример).
UFO just landed and posted this here
Лямбды теперь тоже добавляют веселья. У меня вот на днях было: цикл по коллекции, в нём значения из коллекции передаются в лямбду, захват по ссылке, но работает криво — или выдаёт неверные значения, или падает. Потом оказалось, что лямбда выполняется вообще в другое время, а то и в другом потоке, когда переменная цикла уже давно уничтожена. А по виду функции, которая принимает лямбду, не всегда можно сказать, синхронное там выполнение или нет, надо ли учитывать время жизни передаваемых объектов или лучше просто копировать их.
UFO just landed and posted this here
А что в этой статье может не понравиться программистам?
См. комментарии ниже. :)
UFO just landed and posted this here
Попробуйте заменить «статический анализ» на «статическая типизация». Ничего не поменяется. Разве что прикрутить к существующему языку статическую типизацию внешними средствами сложнее. А трейдофы практически такие же.
Интересное мнение. Чем-нибудь подкреплено?
А то для указанных языков типизация то статическая, а анализатор зачем-то используется.
А то для указанных языков типизация то статическая, а анализатор зачем-то используется.
Так они не пересекаются, вот и используют оба. А с практической точки зрения очень похоже: тебе надо постоянно подсказывать компилятору (статическая типизация) или анализатору (статический анализ), что ты имел в виду. Потому что вывести самостоятельно они это не могут. Это постоянная работа, которая требуется здесь и сейчас. За это возникает вознаграждение когда-нибудь потом, по мере обнаружения ошибок.
Соответственно, все претензии, которые высказываются к статическому анализу — «зачем нам делать лишнюю работу сейчас», можно предъявить и статической типизации.
Соответственно, все претензии, которые высказываются к статическому анализу — «зачем нам делать лишнюю работу сейчас», можно предъявить и статической типизации.
Лучше замените «статический анализ» на «окропление святой водой» или «битье в шаманский бубен». Эффективность на рубль затрат будет примерно та же. Хотя… наверное у каждого айтишника были ситуации, когда помог именно бубен. Кто-то и ракеты перед стартом освящает.
PVS-studio пока не проверял, а CPP-check… Эффективность близкая к нулю. За 3 дня разбора — ничего существенного. При этом варнинги компиляторов — примерно процентов 50 — это реальные ошибки. Хинты компиляторов — процентов 10 указывают на ошибку.
Вот только бубен стоит 200-300 рублей, а PVS-Studio — немерянные килобаксы. Стоит ли их тратить на технологию с «недоказанной эффективностью» — непонятно.
PVS-studio пока не проверял, а CPP-check… Эффективность близкая к нулю. За 3 дня разбора — ничего существенного. При этом варнинги компиляторов — примерно процентов 50 — это реальные ошибки. Хинты компиляторов — процентов 10 указывают на ошибку.
Вот только бубен стоит 200-300 рублей, а PVS-Studio — немерянные килобаксы. Стоит ли их тратить на технологию с «недоказанной эффективностью» — непонятно.
Вот про это и статья…
Увы, весь ваш бог — это антиреклама PVS-studio. Судя по вашему блогу, реальные, мешающие пользователям ошибки PVS-studio помогает исправлять намного реже бубна. ВО всем вашем блоге — 1-2 примера про то, что у человека был реальный баг, он запустил PVS-studio и баг нашелся. Зато — примеров про полезность бубна — сотни.
Зато — цена статического анализа — намного больше цены бубна. Дело не только в стоимости, но и во времени выполнения и анализа. В основном — анализа. И это касается не только ложных срабатываний. Но и вполне реальных, но десятой степени важности. Потому и запускают бесплатный cppcheck редко, что затраты на его запуск не оправдываются. Максимум — проверить перед релизом, что мин нет.
Зато — никто не пишет в комментариях «спасибо, мы за этим багом год гонялись». Основная реакция — «извините, у нас есть реально важные вещи. Те мелочи, что вы нарыли — мы когда-нибудь исправим». И это — главная антиреклама статического анализа.
Причина простая: основные баги — в алгоритмах. В работе аналитиков. математиков. постановщиков, алгоритмистов. А багов при кодировании — не так много.
Отдельный вопрос про уязвимости. Ну в общем ваш представитель сам признал, что пока что примеров нахождения реальных, эксплуатируемых уязвимостей у вас нет. Но как раз тут вам может повезти.
А основной эффект от статического анализатора — это введение в заблуждение менеджеров. «Раз мы потратили килобаксы — значит наш код будет без ошибок». Это в принципе неверно, потому что большинство ошибок — алгоритмические. Статический анализ, бубен, окропление святой водой — все это плацебо. Да, немного помогает. Но зато — оттягивает время на реально полезные меры. Те, что дают эффекта намного больше стоимости.
Зато — цена статического анализа — намного больше цены бубна. Дело не только в стоимости, но и во времени выполнения и анализа. В основном — анализа. И это касается не только ложных срабатываний. Но и вполне реальных, но десятой степени важности. Потому и запускают бесплатный cppcheck редко, что затраты на его запуск не оправдываются. Максимум — проверить перед релизом, что мин нет.
Зато — никто не пишет в комментариях «спасибо, мы за этим багом год гонялись». Основная реакция — «извините, у нас есть реально важные вещи. Те мелочи, что вы нарыли — мы когда-нибудь исправим». И это — главная антиреклама статического анализа.
Причина простая: основные баги — в алгоритмах. В работе аналитиков. математиков. постановщиков, алгоритмистов. А багов при кодировании — не так много.
Отдельный вопрос про уязвимости. Ну в общем ваш представитель сам признал, что пока что примеров нахождения реальных, эксплуатируемых уязвимостей у вас нет. Но как раз тут вам может повезти.
А основной эффект от статического анализатора — это введение в заблуждение менеджеров. «Раз мы потратили килобаксы — значит наш код будет без ошибок». Это в принципе неверно, потому что большинство ошибок — алгоритмические. Статический анализ, бубен, окропление святой водой — все это плацебо. Да, немного помогает. Но зато — оттягивает время на реально полезные меры. Те, что дают эффекта намного больше стоимости.
основные баги — в алгоритмах. В работе аналитиков. математиков. постановщиков, алгоритмистов. А багов при кодировании — не так много
Да неужели?
Зачем вы постоянно выделяете рандомные куски фраз жирным? Такое ощущение, что вы периодически на крик срываетесь
Да неужели?
Зачем вы постоянно выделяете рандомные куски фраз жирным? Такое ощущение, что вы периодически на крик срываетесь
Это смысловое ударение. Жирные слова говорятся с нажимом. А вы знаете более лучший способ их передать? Или вообще против rich-text?
Если вы читаете главными баги при кодировании, то советую подумать о том, являются ли баги при кодировании причиной ложных срабатываний PVS-studio. Или почитать соответствующую статью от авторов.
ВО всем вашем блоге — 1-2 примера про то, что у человека был реальный баг, он запустил PVS-studio и баг нашелся.Ну что делать, если нам редко сообщают об интересных найденных ошибках. Да и о большинстве мы всё не можем написать. Почти у всех наших клиентов код закрыт, и они не хотели бы чтобы мы приводили примеры из их кода. Не писать же статью в духе. Компания X нашла ошибку, Y, в коде Z, но X/Y/Z мы не покажем. :)
Косвенным подтверждением эффективности анализатора и что он находит серьёзные ошибки, является то, что многие компании год из года продлевают лицензии. Это Жжжж не с проста.
Потому и запускают бесплатный cppcheck редко, что затраты на его запуск не оправдываются.Запускайте что-то посерьезней и поудобней. Например, можно настроить PVS-Studio чтобы он запускался ночью и отправлял письма тем, в чьём коде нашлось подозрительное место. Очень удобно.
Причина простая: основные баги — в алгоритмах. В работе аналитиков. математиков. постановщиков, алгоритмистов. А багов при кодировании — не так много. А основной эффект от статического анализатора — это введение в заблуждение менеджеров.Большое спасибо за ваш комментарий. Благодаря ему моя статья становится что ли более достоверной. А то получается, что я описываю неких абстрактных людей. А Вы как бы воплощаете заблуждения в реальность. :)
А вы свой код не проверяете разве? Пока что вы дали только антирекламу: "Мы тут проверили свой код и нашли ерунду". И это полностью соответствует моим ощущениям от cppcheck.
Возьмите любое ложное срабатывание. И оцените — сколько процентов — не исправимо в принципе, сколько — отсутствие функциональности, сколько — ошибки алгоритма, сколько — ошибки в коде, не находимые статанализом, и сколько ошибок на самом деле нашел статанализатор во время разработки.
Возьмите статистику по тестированию. У вас в посте рассказано про 7 методик тестирования. Оцените, какой процент ошибок находится именно статанализом.
Сделайте двойное слепое рандомизированное исследование. Насколько статанализ уменьшает количество ошибок? И насколько он лучше плацебо?
Я рад, что вы тоже читали про жопу Хэнка. В ответ могу сказать, что бубен используется даже на атомных электростанциях, а сбербанк освящает отделения.
Как и любое целование жопы Хэнка, бубен дает как минимум плацебо-эффект. Вопрос лишь в том, что на тысячу рублей затрат эффект от бубна намного больше, чем от статанализа. Если вы знаете условия, при которых эффект от статанализа выше, чем от бубна — то честно опишите их.
У вас есть способ по номеру строки и имени модуля автоматически найти комит, который внес ошибку? Или вы хотите просто отправлять тому, кто последний раз правил данный кусок? Первое — очень интересно. Особенно, если там не банальный bisect, а что-то умное.
Если вернее — мои заблуждения совпадают с вашей антирекламой. Если бы вы написали: "У нас тут плагин выпал из станализа, в итоге там было 100500 ошибок, мы выпустили плагин на год позже и он до сих пор глючен как тупайя" может быть я и поверил бы. Но вы написали честно.
А вот и ещё подтверждение. Опять ваша статья о ложных срабатываниях. И вы опять честно говорите, что дело в алгоритмах, а не в багах в коде. И ни один супер-пупер анализатор не поможет вам уменьшить число ложных срабатываний — для этого все равно нужно развивать алгоритмы.
Возможно, есть некоторая узкая область, где статанализатор оправдывает свою цену. Но тогда нужно просто её описать. Как вариант — это веб-проекты, где действительно ошибка может стать уязвимостью.
Возьмите любое ложное срабатывание. И оцените — сколько процентов — не исправимо в принципе, сколько — отсутствие функциональности, сколько — ошибки алгоритма, сколько — ошибки в коде, не находимые статанализом, и сколько ошибок на самом деле нашел статанализатор во время разработки.
Возьмите статистику по тестированию. У вас в посте рассказано про 7 методик тестирования. Оцените, какой процент ошибок находится именно статанализом.
Сделайте двойное слепое рандомизированное исследование. Насколько статанализ уменьшает количество ошибок? И насколько он лучше плацебо?
Косвенным подтверждением эффективности анализатора и что он находит серьёзные ошибки, является то, что многие компании год из года продлевают лицензии. Это Жжжж не с проста.
Я рад, что вы тоже читали про жопу Хэнка. В ответ могу сказать, что бубен используется даже на атомных электростанциях, а сбербанк освящает отделения.
Как и любое целование жопы Хэнка, бубен дает как минимум плацебо-эффект. Вопрос лишь в том, что на тысячу рублей затрат эффект от бубна намного больше, чем от статанализа. Если вы знаете условия, при которых эффект от статанализа выше, чем от бубна — то честно опишите их.
Например, можно настроить PVS-Studio чтобы он запускался ночью и отправлял письма тем, в чьём коде нашлось подозрительное место. Очень удобно
У вас есть способ по номеру строки и имени модуля автоматически найти комит, который внес ошибку? Или вы хотите просто отправлять тому, кто последний раз правил данный кусок? Первое — очень интересно. Особенно, если там не банальный bisect, а что-то умное.
А Вы как бы воплощаете заблуждения в реальность. :)
Если вернее — мои заблуждения совпадают с вашей антирекламой. Если бы вы написали: "У нас тут плагин выпал из станализа, в итоге там было 100500 ошибок, мы выпустили плагин на год позже и он до сих пор глючен как тупайя" может быть я и поверил бы. Но вы написали честно.
А вот и ещё подтверждение. Опять ваша статья о ложных срабатываниях. И вы опять честно говорите, что дело в алгоритмах, а не в багах в коде. И ни один супер-пупер анализатор не поможет вам уменьшить число ложных срабатываний — для этого все равно нужно развивать алгоритмы.
Возможно, есть некоторая узкая область, где статанализатор оправдывает свою цену. Но тогда нужно просто её описать. Как вариант — это веб-проекты, где действительно ошибка может стать уязвимостью.
Вы усиленно ссылаетесь здесь и в других комментариях на статью "Проверяем исходный код плагина PVS-Studio с помощью PVS-Studio" и говорите «ага, я же говорил, что мало находится». Есть 3 момента, о которых Вы не подумали или сознательно не замечаете.
- Плагин для Visual Studio, это маленькая программа, там просто негде взяться сотням ошибкам.
- В маленькой программе и плотность ошибок меньше.
- Суть статического анализа в регулярных запусках. Мы бы возможно сократили время на поиск некоторых ошибок, если использовали анализатор сразу. Но для такой маленькой программы как плагин об этом и рассуждать особенно смысла нет. Можно вполне обходиться без статического анализа, что мы и делали. Эта статья писалась не для рекламы, а исключительно для того, чтобы наконец было отвечать на вопрос, который уже вызывает зубную боль, проверяли ли мы PVS-Studio с помощью PVS-Studio.
Да почему же, замечаю. Маленькая — это по вашему сколько строк? То есть с какого размера программы PVS-Studio начинает оправдывать свою цену? Это первый важный вопрос.
По моему мнению, маленькая — это программа, написанная малой группой, где тимлид лично читал весь код и помнит его наизусть. В ней может быть и полмиллиона строк кода — тут дело не в размере. С другой стороны, программа в 10 тысяч строк, которую писал десяток авторов — это большая программа (тот самый верблюд, что создан комитетом вместо лошади) и в ней багов будет порядочно. Особенно, если куча авторов делали лишь несколько комитов, то есть не разбирались в коде достаточно долго.
Ну вот вам другая ваша же статья. Выбрана ровно потому, что это детище одного автора (или малой группы). Да, что-то нашлось. Но найденное — явно не соразмерно цене PVS-Studio.
А второй вопрос, это не лучше ли вместо покупки статанализатора купить бубны, освятить компы, покрасить стены в зеленый цвет или сделать какие-то ещё плацебо-мероприятия. Потому что любое плацебо — немного помогает. При каких условиях PVS-studio выгодней бубна, если считать на рубль затрат?
А знаете, как работают там, где цена ошибки — 35-40 тысяч долларов? Там премия равна окладу. А снимается премия со всей службы за 3 часа простоя в месяц. Итог - ноль минут простоя за 3 года, что я отслеживал установленную там нашу систему. И опять вопрос — при каких условиях выгоднее платить за PVS-studio вместо премий (той же суммой) разработчикам?
Кстати, примитивный статанализ я там написал, но применять его не стали. А вот динамический анализ хорошо пошел. Динамический анализ по аварийному сигналу определял, срабатывание какого датчика вызвало аварию. Определялось верно в 99.7% случаев, ложных срабатываний — меньше 0.1%. Ну то есть меряли на 1000 сэмплов и не нашли.
Это некоторый намёк — программа (плагин к отладчику), которая при возникновении исключения находит ошибку — может быть безумно популярной при её разумной цене. Ну и ложных срабатываний в ней немного.
По моему мнению, маленькая — это программа, написанная малой группой, где тимлид лично читал весь код и помнит его наизусть. В ней может быть и полмиллиона строк кода — тут дело не в размере. С другой стороны, программа в 10 тысяч строк, которую писал десяток авторов — это большая программа (тот самый верблюд, что создан комитетом вместо лошади) и в ней багов будет порядочно. Особенно, если куча авторов делали лишь несколько комитов, то есть не разбирались в коде достаточно долго.
Ну вот вам другая ваша же статья. Выбрана ровно потому, что это детище одного автора (или малой группы). Да, что-то нашлось. Но найденное — явно не соразмерно цене PVS-Studio.
А второй вопрос, это не лучше ли вместо покупки статанализатора купить бубны, освятить компы, покрасить стены в зеленый цвет или сделать какие-то ещё плацебо-мероприятия. Потому что любое плацебо — немного помогает. При каких условиях PVS-studio выгодней бубна, если считать на рубль затрат?
А знаете, как работают там, где цена ошибки — 35-40 тысяч долларов? Там премия равна окладу. А снимается премия со всей службы за 3 часа простоя в месяц. Итог - ноль минут простоя за 3 года, что я отслеживал установленную там нашу систему. И опять вопрос — при каких условиях выгоднее платить за PVS-studio вместо премий (той же суммой) разработчикам?
Кстати, примитивный статанализ я там написал, но применять его не стали. А вот динамический анализ хорошо пошел. Динамический анализ по аварийному сигналу определял, срабатывание какого датчика вызвало аварию. Определялось верно в 99.7% случаев, ложных срабатываний — меньше 0.1%. Ну то есть меряли на 1000 сэмплов и не нашли.
Это некоторый намёк — программа (плагин к отладчику), которая при возникновении исключения находит ошибку — может быть безумно популярной при её разумной цене. Ну и ложных срабатываний в ней немного.
UFO just landed and posted this here
Премию снимают со всей службы, включая руководителя службы. Правда, службы у них маленькие, до десятка человек в службы. Насчет Мордашова — не знаю. Думаю, у него дивиденды намного больше оклада.
А вот про «незаконность» — расскажите. Очень интересно аргументацию послушать.
А вот про «незаконность» — расскажите. Очень интересно аргументацию послушать.
Не вы случайно писали статью о российских ракетах, на которые официально тратится ~130000 рублей на освящение церковью?
Слушайте, я вас не понимаю. Ну не нужен вам их продукт, считаете его слишком дорогим, бесполезным и т.д. — не покупайте, не используйте и вообще всячески игнорируйте. Я постоянно читаю этот блог, и постоянно вижу, как вы бегаете по статьям, чтобы рассказать, как вам PVS-Studio безразличен, что он нафиг не нужен, что вообще вы ненастоящий программист и вот это всё. Какой в этом смысл? Не хотите — не используйте. А то сейчас выглядит так: то ли вы просто хейтер, то ли вы всячески демонстрируете свою «нетаковость» и олдфажность, то ли вам очень хочется юзать PVS, но давит жаба, и поэтому вы компенсируете вот таки странным образом. В заключение цитата из Остера:
А кому смотреть противно —
Тот пускай и не глядит.
Мы же в нос к нему не лезем —
Пусть и он не пристает.
И цитата из ФИДО:
«Отпишись и не читай!»
А кому смотреть противно —
Тот пускай и не глядит.
Мы же в нос к нему не лезем —
Пусть и он не пристает.
И цитата из ФИДО:
«Отпишись и не читай!»
Может вы ещё и уголовное дело за оскорбление чувств верующих в PVS-studio возбудите? :-)
Я откомментировал всего 2-3 статьи, то есть меньше 1% статей в блоге PVS-studio. Это вот четко показывает, что ваше отношение к PVS-Studio — религиозно, а критическое мышление у вас отсутствует как класс. В чем-то это даже верно — статанализ надо рассматривать наравне с бубном и другими суевериями. См. замечательную статью про Hype Driven Development
А добился я пока одной честной цифры — меньше 250 KLoc любой статанализ «не обязателен».
Думаю, что добьюсь и остальных цифр, например, с какого размера программы окупается цена PVS-studio, каков экономический эффект и так далее. То есть того, что реально нужно знать до покупки.
Ну а вы — можете и дальше верить, что любая модная технология применима всегда и везде.
Я откомментировал всего 2-3 статьи, то есть меньше 1% статей в блоге PVS-studio. Это вот четко показывает, что ваше отношение к PVS-Studio — религиозно, а критическое мышление у вас отсутствует как класс. В чем-то это даже верно — статанализ надо рассматривать наравне с бубном и другими суевериями. См. замечательную статью про Hype Driven Development
А добился я пока одной честной цифры — меньше 250 KLoc любой статанализ «не обязателен».
Думаю, что добьюсь и остальных цифр, например, с какого размера программы окупается цена PVS-studio, каков экономический эффект и так далее. То есть того, что реально нужно знать до покупки.
Ну а вы — можете и дальше верить, что любая модная технология применима всегда и везде.
Это очень оригинально — умудриться в моих словах о нелогичности вашего поведения найти религиозную веру и еще кучу вещей, которых там и близко не было. Впрочем, я благодарен вам вот за вот эту фразу:
Статанализ надо рассматривать наравне с бубном и другими суевериями
Таким образом, у вас тут религиозный поход против статанализа, как бы вы не изворачивались, утверждая обратное. Чудно, теперь все встало на свои места. Продолжайте писать ваш супербезгрешный безошибочный код и дальше да считайте статанализ модной фигней, которой при царе Горохе-то не было и ничего, жили как-то.
ЗЫ:
[offrop]
ваш плевок мне в карму воспринимаю исключительно как как ваше бессилие в попытках внятно аргументировать, чего вам так не нравится в PVS и статанализе вообще. Засим откланиваюсь, потому как вести с вами конструктивный диалог явно не выйдет (по причине религиозной веры, таки да, только вот чьей — боооольшооой вопрос).
[/offtop]
Статанализ надо рассматривать наравне с бубном и другими суевериями
Таким образом, у вас тут религиозный поход против статанализа, как бы вы не изворачивались, утверждая обратное. Чудно, теперь все встало на свои места. Продолжайте писать ваш супербезгрешный безошибочный код и дальше да считайте статанализ модной фигней, которой при царе Горохе-то не было и ничего, жили как-то.
ЗЫ:
[offrop]
ваш плевок мне в карму воспринимаю исключительно как как ваше бессилие в попытках внятно аргументировать, чего вам так не нравится в PVS и статанализе вообще. Засим откланиваюсь, потому как вести с вами конструктивный диалог явно не выйдет (по причине религиозной веры, таки да, только вот чьей — боооольшооой вопрос).
[/offtop]
В PVS мне не нравится цена, а в модных технология вообще — попытка выдать очередную модную фишку за панацею. Что и было написано не менее пяти раз.
Любая технология чуть ли не половину эффекта дает до своего реального внедрения. Это собственно плацебо (или почти плацебо). Не важно, красите ли вы стены в зеленый цвет, раздаете сотрудникам бубны, устанавливаете теннисные столы, освящаете кабинеты или внедряете статанализ — какой-то эффект будет всегда.
Есть подозрение, что основной эффект от статанализа — это всего лишь мотивация сотрудников. «Ой. руководство решит, что у меня багов много, буду-ка я писать аккуратней». Беда в том, что замотивировать можно и меньшими деньгами, чем плата за PVS-studio.
Теоретически статанализ полезен, но самые полезные 9% статанализа встроены к компилятор. Все остальное — это гонка за оставшимися 3-5 процентами. Стоит ли платить немалые деньги просто за собственный перфекционизм — это большой вопрос.
Что касается меня, то считайте, что это крестовый поход против любой модной технологии, которую советуют применять всегда и везде, «невзирая на памятник».
Ну должен же быть среди толпы модников хоть один взрослый, понимающий, что это всего лишь мода и она пройдет?
Любая технология чуть ли не половину эффекта дает до своего реального внедрения. Это собственно плацебо (или почти плацебо). Не важно, красите ли вы стены в зеленый цвет, раздаете сотрудникам бубны, устанавливаете теннисные столы, освящаете кабинеты или внедряете статанализ — какой-то эффект будет всегда.
Есть подозрение, что основной эффект от статанализа — это всего лишь мотивация сотрудников. «Ой. руководство решит, что у меня багов много, буду-ка я писать аккуратней». Беда в том, что замотивировать можно и меньшими деньгами, чем плата за PVS-studio.
Теоретически статанализ полезен, но самые полезные 9% статанализа встроены к компилятор. Все остальное — это гонка за оставшимися 3-5 процентами. Стоит ли платить немалые деньги просто за собственный перфекционизм — это большой вопрос.
Что касается меня, то считайте, что это крестовый поход против любой модной технологии, которую советуют применять всегда и везде, «невзирая на памятник».
Ну должен же быть среди толпы модников хоть один взрослый, понимающий, что это всего лишь мода и она пройдет?
Безотносительно от PVS-studio (для java его нет и вряд ли в обозримом времени появится) — стат.анализ помогает даже в условно-мелких проектах. На своём примере знаю, что применение стат. анализа помогло:
- идентифицировать несколько багов, могущих испортить выводимые данные в многопоточном окружении (к сожалению базовая библиотека форматированного вывода даты в Java непригодна к использования в многопоточном окружении, т.к. использует общий объект с внутренним состоянием)
- увидеть несколько опасных мест, которые в ряде случаев могли сработать в виде багов
- увидеть места, которые можно было упростить (чем повышалась читабельность).
Сколько это в деньгах — сказать не смогу, не менеджер. Но в любом случае в цену багов входят не только стоимость работы девов/qa, но и репутационные издержки, а в некоторых случаях — и прямые финансовые потери ($440 000 000, помог ли бы им стат. анализ неизвестно, о таких фейлах наружу инфу стараются не выпускать, но вероятность такого исхода была бы всё же ниже).
PS и да, согласен с Ахриманом — ваше хейтерство PVSов сильно похоже на религозное мракобесие… успокойтесь уже. Не нравятся они вам — забейте и не смотрите их стати.
Знаете, при риске в 440 миллионов, я бы не только освятил проект. Но ещё и позвал бы муллу, равина и ламу. Ну и настоящего шамана — это уж само собой.
Но граница выгодности — это как раз самый интересный момент. И когда о нем умалчивают — появляется желание объяснить толпемалолеток молодежи, что эта граница есть. Благо большая часть хабра годится мне в дети.
А про ваш проект мне интересен другой вопрос. Сколько времени вы потеряли на проверку результатов статанализа и сколько бы стоили те фичи, которые бы вы смогли за это время написать? Ну или сколько реально проявляющих багов могли бы за это время найти?
P.S. Забить не смогу, я обещал проверить свой проект после вычистки cppcheck и clang static anayuzer и написать честный отчет, насколько PVS-studio лучше бесплатных проектов. Рабочая гипотеза примерно совпадает с тем, что вы написали — некая мелочевка нашлась, но времени не окупает.
Но граница выгодности — это как раз самый интересный момент. И когда о нем умалчивают — появляется желание объяснить толпе
А про ваш проект мне интересен другой вопрос. Сколько времени вы потеряли на проверку результатов статанализа и сколько бы стоили те фичи, которые бы вы смогли за это время написать? Ну или сколько реально проявляющих багов могли бы за это время найти?
P.S. Забить не смогу, я обещал проверить свой проект после вычистки cppcheck и clang static anayuzer и написать честный отчет, насколько PVS-studio лучше бесплатных проектов. Рабочая гипотеза примерно совпадает с тем, что вы написали — некая мелочевка нашлась, но времени не окупает.
Сколько времени вы потеряли на проверку результатов статанализа и сколько бы стоили те фичи, которые бы вы смогли за это время написать? Ну или сколько реально проявляющих багов могли бы за это время найти?
Полдня на настройку автоматического сбора статистики по стат-анализу в рамках CI. Полдня на снятие сливок. Самостоятельный поиск тех самых багов с многопоточностью съел бы вряд ли меньше дня… а мог и больше слопать. При этом когда бы они сыграли — фиг его знает… Но последствия, хоть и только репутационные, но были бы весьма неприятны. Остальные бонусы шли оверхедом и в принципе всё выше минора по оценке стат-анализа было оправдано в разборе и правке.
У нас с вами — разные предпосылки. Вы верите, что можете исправить все баги, а я знаю, что могу лишь уменьшить их плотность и увеличить MTBF.
Вы потеряли день на нахождение багов, которые не проявлялись в вашем проекте. Вместо этого вы могли исправить 3-15 багов, которые проявляются и мешают вашим пользователям. Или написать пару позарез нужных фичей.
Правилен ли такой обмен? Стоит ли менять реально полезную работу на лишь потенциально полезную?
Другой случай, если бы у вас в этот момент вообще бы не было никакой полезной работы. Вот тогда обмен правильный. Но подобная ситуация (то есть простой) бывает только на саппорте. У девелоперов она редкость.
Вы потеряли день на нахождение багов, которые не проявлялись в вашем проекте. Вместо этого вы могли исправить 3-15 багов, которые проявляются и мешают вашим пользователям. Или написать пару позарез нужных фичей.
Правилен ли такой обмен? Стоит ли менять реально полезную работу на лишь потенциально полезную?
Другой случай, если бы у вас в этот момент вообще бы не было никакой полезной работы. Вот тогда обмен правильный. Но подобная ситуация (то есть простой) бывает только на саппорте. У девелоперов она редкость.
А давайте теперь еще дружно начнем забивать на рост тех. долга, писать говнокод лишь бы работал, забьем на проектирование, документацию, производительность, написание тестов… Ведь вместо этого можно радостно новые фичи добавлять или мешающие пользователям баги фиксить.
Звучит абсурдно, не правда ли? Исправление косяков найденных стат. анализом это вещь ровно того же порядка. К сожалению в моей сфере деятельности такие инструменты отсутствуют, да что там, даже тесты пишут доли процента и я не в их числе, но сам не раз искал и исправлял ошибки возникшие по причине опечаток и копипаста, при этом времени уходила уйма.
// Не удержался все таки…
Звучит абсурдно, не правда ли? Исправление косяков найденных стат. анализом это вещь ровно того же порядка. К сожалению в моей сфере деятельности такие инструменты отсутствуют, да что там, даже тесты пишут доли процента и я не в их числе, но сам не раз искал и исправлял ошибки возникшие по причине опечаток и копипаста, при этом времени уходила уйма.
// Не удержался все таки…
Звучит абсолютно нормально. Именно так и делается MVP, а так же макеты и прототипы.
Про то, что рост технического долга — это не так плохо, есть достаточно много статей на хабре. Например эта или эта.
Ну да, есть люди, которые из принципа не берут кредиты. Точно так же есть люди, которые не делают технический долг. Но разумная стратегия — это использование и кредитов и технического долга для ускорения развития.
Если вам так хочется написать статанализ на 1С я, наверное, могу поделиться исходниками синтаксического анализатора 1С.
Вам просто было лень поискать. Вот вам статанализатор для 1С. Попробуйте проверить им свои проекты, а потом уже на опыте расскажите нам про его полезность.
Про то, что рост технического долга — это не так плохо, есть достаточно много статей на хабре. Например эта или эта.
Ну да, есть люди, которые из принципа не берут кредиты. Точно так же есть люди, которые не делают технический долг. Но разумная стратегия — это использование и кредитов и технического долга для ускорения развития.
К сожалению в моей сфере деятельности такие инструменты отсутствуют
Вам просто было лень поискать. Вот вам статанализатор для 1С. Попробуйте проверить им свои проекты, а потом уже на опыте расскажите нам про его полезность.
Хм, действительно, посыпаю голову пеплом что умудрился такую штуку проморгать, хотя когда впервые про pvs услышал поискал на тему 1с, в то время почему то не нашел. Пока что не имею возможности приобрести, но в течении нескольких месяцев возможно сподоблюсь и отпишусь.
Про MVP слышал конечно, и не считаю что тех. долг нужно тут же исправлять как только появится, но ведь до маразма доходит же что функциональность пишется вообще без проектирования, с дикими костылями и говнокодом, и в таком виде и замораживается, ибо трогать страшно — развалится. Впрочем даже если и не трогать — ошибки лезут из всех щелей, приходится на каждом проекте их заново править. В итоге дорабатывать нашу систему под каждого заказчика это такая боль… Особенно если это правки в существующем функционале.
Про MVP слышал конечно, и не считаю что тех. долг нужно тут же исправлять как только появится, но ведь до маразма доходит же что функциональность пишется вообще без проектирования, с дикими костылями и говнокодом, и в таком виде и замораживается, ибо трогать страшно — развалится. Впрочем даже если и не трогать — ошибки лезут из всех щелей, приходится на каждом проекте их заново править. В итоге дорабатывать нашу систему под каждого заказчика это такая боль… Особенно если это правки в существующем функционале.
Это то, что у Джоэла называется «огонь и движение»?
(И пятилетней давности новость про патент танка, стреляющего экскрементами.)
(И пятилетней давности новость про патент танка, стреляющего экскрементами.)
UFO just landed and posted this here
Вы не правы, но идея богатая.
Качественный статический анализатор может найти и ошибки в сложных алгоритмах. Если у вас программа перебирает сложный набор состояний нескольких переменных в цепочке условий, статический анализ легко предупредит вас, например, что вы одно и то же состояние проверяете дважды или что две проверки взаимоисключающие.
Да, разумеется, об этом классе ошибок и бесплатный gcc предупреждает (если писать через switch). Вопрос в том, стоит ли за платить за это немерянные килобаксы.
По личному опыту использование cppcheck не оправдалось. То есть время, потраченное на разбор — не оправдывается тем, что он нашел.
А ошибки в алгоритма — это, например, неверное прочтение ИКД (интерфейсно-контрольный документ). Или баг в самом ИКД (такое было в ГЛОНАСС). Или использование не того алгоритма. Или забыли реализовать полезную функциональность.
По личному опыту использование cppcheck не оправдалось. То есть время, потраченное на разбор — не оправдывается тем, что он нашел.
Типичный баг, найденный cppcheck
Угу, если пираты захватят корабль, вскроют наш ящик, спаяют кабель, зайдут с консоли и вместо rm -rf / начнут вводить очень длинные параметры командной строки — будет плохо. Но это не те проблемы. которые есть смысл исправлять. Потому как пиратам проще пристрелить капитана. Ну раз уж они все равно на судне.
А ошибки в алгоритма — это, например, неверное прочтение ИКД (интерфейсно-контрольный документ). Или баг в самом ИКД (такое было в ГЛОНАСС). Или использование не того алгоритма. Или забыли реализовать полезную функциональность.
UFO just landed and posted this here
В общем, надо не стесняться заставлять программистов использовать статический анализ кода. Пусть даже не PVS-Studio, пусть это будет хотя бы Cppcheck (выполняет простые проверки, но зато бесплатен). Это уже будет большим хорошим делом. Программист, конечно, может капризничать, поэтому стоит проявить твердость.
Как видите, это не я, это команда PVS-Studio.
Лично я экстраполирую их опыт проверки их собственного кода. Как видите — найденное вряд ли стоит потраченного времени.
UFO just landed and posted this here
Очевидно, что вы не читали их статью
Увы, я тоже автор статанализатора. Для очень простых языков, но тем не менее. И к сожалению я знаю, что может найти статанализ, а что не может. Устранение бага, который мог быть пойман анализатором, как правило, не стоит потраченного на него времени.
Возможно, есть исключение для софта, баги в котором являются уязвимостями. Но на софт к такому не относится. Если уж ящик открыли — то проще сжечь процессор пьезозажигалкой, чем искать уязвимости в софте.
Из-за недосмотра C# код плагина для Visual Studio не был добавлен в ежедневные ночные проверки, которые мы проводим. И, соответственно, в отличие от ядра анализатора, ошибки в нем не замечались на протяжении всего развития C# PVS-Studio.
Увы, я тоже автор статанализатора. Для очень простых языков, но тем не менее. И к сожалению я знаю, что может найти статанализ, а что не может. Устранение бага, который мог быть пойман анализатором, как правило, не стоит потраченного на него времени.
Возможно, есть исключение для софта, баги в котором являются уязвимостями. Но на софт к такому не относится. Если уж ящик открыли — то проще сжечь процессор пьезозажигалкой, чем искать уязвимости в софте.
Через switch вы переберёте конкретные состояния одной переменной. Анализатор может больше. Скажем, такой код, чисто для примера:
int a = getA();
int b = getB();
if(a >= 0 && b <= 0) { ... }
else if(a <= 0 && b >= 0) { ... }
else if(a < 0) {
...
...
if(b == 1) {...} // анализатор: это у вас тут всегда ложно
}Не знаю, может ли такое cppcheck.
— Я духов вызывать могу из бездны!
— И я могу, и всякий это может. Вопрос лишь, явятся ль они на зов.
То есть этот код — только переписывать.
Начнем с того, что PVS-Studio прежде всего ругнется на int a = getA(); чем-нибудь типа V707. Потом так же на int b = getB();, потом — на if(a <= 0 && b >= 0) — ибо ситуация a=0, b=0 проверена раньше.
Если… обозначает код того же уровня, то вы получите предупреждений — примерно столько же, сколько строк в коде. И сумеете ли вы найти в этой каше то, что важно лично вам — это большой вопрос.
Есть лишь один случай, когда нужно писать такую лапшу- когда она описана в ГОСТ или РД. Ну как пример — РД 50-25645.325-89.
.Вот тут и однобуквенные переменные и куча других странностей. Но хочешь результат, совместимый с другими — значит делаешь по ГОСТ.
UFO just landed and posted this here
Да, заметит быстрее. Но будет ли это дешевле? Личный вертолет — быстрее велосипеда. Вы себе вертолет уже купили?
Один из авторов PVS-Studio дал нижнюю оценку эффективности в 250КLoc. Вы с этим согласны?
Один из авторов PVS-Studio дал нижнюю оценку эффективности в 250КLoc. Вы с этим согласны?
прежде всего ругнется на int a = getA(); чем-нибудь типа V707
Кто вам сказал, что это глобальные переменные? Да и суть не в именах.
потом — на if(a <= 0 && b >= 0) — ибо ситуация a=0, b=0 проверена раньше.
Почему вы считаете, что на это условие нужно ругаться? Я хочу, чтобы (a, b) = (-1, 0) и (0, 1) заходили в эту ветку. Как вы напишете второе условие?
Почему вы считаете, что на это условие нужно ругаться? Я хочу, чтобы (a, b) = (-1, 0) и (0, 1) заходили в эту ветку. Как вы напишете второе условие?
Там первое условия if(a >= 0 && b <= 0) съест этот случай
Возможно, я плохо выразился или вы плохо подумали. При a = -1, b = 0 мы не зайдём в первую ветку. При a = 0, b = 1 мы тоже не зайдём в первую ветку.
Скорее всего вы пропустили нюанс: в условие a <= 0 && b >= 0 входит в том числе случай a,b=0, который проверен условием выше, а потому статический анализатор на него должен агриться.
Но выполнение такого требования будет работать в ущерб читабельности второго условия — его нужно будет расширять, например до (a == 0 && a != b || a < 0) && b >=0.
Причина простая: основные баги — в алгоритмах. В работе аналитиков. математиков. постановщиков, алгоритмистов. А багов при кодировании — не так много.Некоторые мысли про это.
Спасибо. Прямо там вам и ответил.
> Это в принципе неверно, потому что большинство ошибок — алгоритмические.
С сотрудниками той квалификации, которую Вы описываете тут и в одном из предыдущих постингов, где мы общались — возможно, так и есть.
Но это никак не соответствует основной массе программистов. Могу сказать за себя — я периодически делаю такие ошибки, которые выявляются статическими анализаторами. И если бы получить честный опрос всех программистов — таких было бы, думаю, 99%.
Я крайне рад, что Вы исключение.
С сотрудниками той квалификации, которую Вы описываете тут и в одном из предыдущих постингов, где мы общались — возможно, так и есть.
Но это никак не соответствует основной массе программистов. Могу сказать за себя — я периодически делаю такие ошибки, которые выявляются статическими анализаторами. И если бы получить честный опрос всех программистов — таких было бы, думаю, 99%.
Я крайне рад, что Вы исключение.
Давайте не путать. я тоже делаю ошибки, которые выявляются компиляторами. Дело не в этом, а в том, каких ошибок больше.
Если вы пишете printf(data) вместо printf("%s",data) — это может быть ошибкой класса «недостаточный контроль ввода». Да, конкретно эту ошибку статанализатор может обнаружить. А вот что, иных проверок входных данных нет — не обнаружит. Потому, что отсутствие проверок — это мисфича, то есть просто отсутствие кода.
А источник ошибки — это ТЗ. При его написании не подумали, что может влезть хакер и послать заведомо неверные данные. Точнее вначале был TCP-интерфейс между процессами на одной машине. И там хакер не мог влезть, ибо машина была вне инета. Потом — процессс перенесли на другую машину. А потом — связь стала через инет. И вот в этот момент — забыли, что нужно добавить защиту. Забыли на уровне ТЗ.
И вот таких ошибок — явно больше, чем чисто кодовых.
И вот тут стоит вопрос — стоит ли тратить немерянные килобаксы на PVS-Studio? Или их эффективней потратить на иные методики. С учетом того, что статанализ не обнаруживает очень большие классы ошибок, особенно ошибки в ТЗ.
А вы говорите о другом. О том, что бесплатный PVS-studio полезен. И с этим-то я не спорю.
А вот бесплатный cppcheck на мой вкус — не оправдал потраченное на разбор и исправления время. Но может быть в иных условиях — и он оправдается.
Ну как пример. Маленький проект нового сотрудника (пока юниор). 1250 строк (+наша библиотека). В компиляторе (BCB 5,0) варнинги были включены избирательно. Включил все варниги — чисто. cppcheck — 2 ошибки, что область видимости могла быть и поуже и 33 ошибки, что сppcheck предлагает писать ++i вместо i++. Ну то есть ничего, что стоит править.
Подпиливаю напильником, компилирую gcc с -Wall -Wextra. 33 warning, среди них достаточно серьезные, вроде «enumeration value ‘xxxx’ not handled in switch». Ну в общем это уже стоит анализировать.
PVS-Studio запускать не стал — побоялся критики, что не в том режиме запустил. Да и смысл запускать до правки того, что нашел gcc?
А в алгоритмике… проект — макетный. Отлажен с одной версией одного устройства. Беглый взгляд на код показывает, что если у устройства сменится прошивка — придет пушной зверек. Выдачи сообщений при ошибке открытия файла — просто не вижу. Ну в общем мисфичей — полно.
Для макетного проекта эти мисфичи — нормальны. Нам действительно пока что данный проект нужен всего лишь для дальнейшей отладки прибора. Но… никакой статанализ не выявит недостатки так, как 2-3 часа чтения кода.
Так что тест подтверждает выводы: cppcheck не стоит потраченного на него времени, а PVS-Studo — если и оправдывает свои килобаксы, то лишь в специфических условиях.
Подозреваю, что основное условие, когда PVS-studio становится выгодным — это отсутствие у проекта девелопера, который помнит весь проект. То есть в условиях взаимозаменяемости девелоперов. Мне кажется, что это условие — важнее тех 250KLoc о которых говорили авторы PVS-studio.
Если вы пишете printf(data) вместо printf("%s",data) — это может быть ошибкой класса «недостаточный контроль ввода». Да, конкретно эту ошибку статанализатор может обнаружить. А вот что, иных проверок входных данных нет — не обнаружит. Потому, что отсутствие проверок — это мисфича, то есть просто отсутствие кода.
А источник ошибки — это ТЗ. При его написании не подумали, что может влезть хакер и послать заведомо неверные данные. Точнее вначале был TCP-интерфейс между процессами на одной машине. И там хакер не мог влезть, ибо машина была вне инета. Потом — процессс перенесли на другую машину. А потом — связь стала через инет. И вот в этот момент — забыли, что нужно добавить защиту. Забыли на уровне ТЗ.
И вот таких ошибок — явно больше, чем чисто кодовых.
И вот тут стоит вопрос — стоит ли тратить немерянные килобаксы на PVS-Studio? Или их эффективней потратить на иные методики. С учетом того, что статанализ не обнаруживает очень большие классы ошибок, особенно ошибки в ТЗ.
А вы говорите о другом. О том, что бесплатный PVS-studio полезен. И с этим-то я не спорю.
А вот бесплатный cppcheck на мой вкус — не оправдал потраченное на разбор и исправления время. Но может быть в иных условиях — и он оправдается.
Ну как пример. Маленький проект нового сотрудника (пока юниор). 1250 строк (+наша библиотека). В компиляторе (BCB 5,0) варнинги были включены избирательно. Включил все варниги — чисто. cppcheck — 2 ошибки, что область видимости могла быть и поуже и 33 ошибки, что сppcheck предлагает писать ++i вместо i++. Ну то есть ничего, что стоит править.
Подпиливаю напильником, компилирую gcc с -Wall -Wextra. 33 warning, среди них достаточно серьезные, вроде «enumeration value ‘xxxx’ not handled in switch». Ну в общем это уже стоит анализировать.
PVS-Studio запускать не стал — побоялся критики, что не в том режиме запустил. Да и смысл запускать до правки того, что нашел gcc?
А в алгоритмике… проект — макетный. Отлажен с одной версией одного устройства. Беглый взгляд на код показывает, что если у устройства сменится прошивка — придет пушной зверек. Выдачи сообщений при ошибке открытия файла — просто не вижу. Ну в общем мисфичей — полно.
Для макетного проекта эти мисфичи — нормальны. Нам действительно пока что данный проект нужен всего лишь для дальнейшей отладки прибора. Но… никакой статанализ не выявит недостатки так, как 2-3 часа чтения кода.
Так что тест подтверждает выводы: cppcheck не стоит потраченного на него времени, а PVS-Studo — если и оправдывает свои килобаксы, то лишь в специфических условиях.
Подозреваю, что основное условие, когда PVS-studio становится выгодным — это отсутствие у проекта девелопера, который помнит весь проект. То есть в условиях взаимозаменяемости девелоперов. Мне кажется, что это условие — важнее тех 250KLoc о которых говорили авторы PVS-studio.
Собственно посмотрите на те программы, которыми вы пользуетесь. Как часто вы находите в них баги? А как часто сожалеете, что в них нету нужной вам фичи? А как часто оказывается, что вас не устраивает поведение программы, но это by design?
UFO just landed and posted this here
Падает — это аварийно завершает выполнение без сохранения? Тогда это design-bug.
В Windows — структурные исключения. Любую программу можно написать так, чтобы при аппаратных exception, она не завершала работу, а выдавала сообщение и давала возможность продолжить работу. Если бояться за порчу данных — их можно защитить проверкой CRC или MD5. Так сделано в VCL (delphi, с builder и так далее).
То, что word падает без сохранения — это ровно такой же design-bug.
Увы, design-баги не находятся статанализом.
В Windows — структурные исключения. Любую программу можно написать так, чтобы при аппаратных exception, она не завершала работу, а выдавала сообщение и давала возможность продолжить работу. Если бояться за порчу данных — их можно защитить проверкой CRC или MD5. Так сделано в VCL (delphi, с builder и так далее).
То, что word падает без сохранения — это ровно такой же design-bug.
Увы, design-баги не находятся статанализом.
UFO just landed and posted this here
Обработка исключений. Она сводит критические ошибки к обходимым, При этом действует сразу на все ошибки.
А устранить все исключения на бытовом компе не реально. Всегда возможен сбой памяти из-за космических лучей. Там, где надо, чтобы исключений не было — там используются два двухголовых компа. Каждый двухголовый — повторяет все операции на обоих процессорах и своей памяти. Если процессоры разошлись хоть на бит — управление передается второй паре двухголовых.
А устранить все исключения на бытовом компе не реально. Всегда возможен сбой памяти из-за космических лучей. Там, где надо, чтобы исключений не было — там используются два двухголовых компа. Каждый двухголовый — повторяет все операции на обоих процессорах и своей памяти. Если процессоры разошлись хоть на бит — управление передается второй паре двухголовых.
Те, кто не обрабатывает исключения — похожи на людей, которые считают, что дом имеет право развалиться из-за трещины в одном кирпиче.
Подходишь к дому 18века. Некоторые кирпичи — крошатся в руках. А дом стоит. Ибо строители никогда не надеятся, что все кирпичи будут без багов
Подходишь к дому 18века. Некоторые кирпичи — крошатся в руках. А дом стоит. Ибо строители никогда не надеятся, что все кирпичи будут без багов
UFO just landed and posted this here
Не было таких ошибок в коде, так что не проверял.
UFO just landed and posted this here
[SARCASM ON]
А откуда вы знаете, что вы не шпион гондураса? Может быть вас во сне завербовали? А давайте вы купите нашу программу за полмиллиона, мы тогда вас проверим и скажем, шпион вы или нет. Да, мы умеем проверять не только на Гондурас. Ещё Гватемала и 50 других стран. Из европейский, правда, только Монако, Люксембург и Андорра, но этого тоже не мало,
[SARCASM OFF]
Неужели вы думаете, что я не знаю наизусть код своего проекта? Проекты до 100 тысяч строк помнятся целиком.
А в помните каждый час своей жизни, чтобы утверждать, что вас не завербовали в шпионы?
А откуда вы знаете, что вы не шпион гондураса? Может быть вас во сне завербовали? А давайте вы купите нашу программу за полмиллиона, мы тогда вас проверим и скажем, шпион вы или нет. Да, мы умеем проверять не только на Гондурас. Ещё Гватемала и 50 других стран. Из европейский, правда, только Монако, Люксембург и Андорра, но этого тоже не мало,
[SARCASM OFF]
Неужели вы думаете, что я не знаю наизусть код своего проекта? Проекты до 100 тысяч строк помнятся целиком.
А в помните каждый час своей жизни, чтобы утверждать, что вас не завербовали в шпионы?
UFO just landed and posted this here
Думаю, что вы все-таки шпион Гондураса. Просто платить не хотите. :-)
ЧСВ у меня скорее заниженное, компилятор мне об ошибках рапортует ежедневно. Не в этом дело. А в том, что ошибки, найденные станализатором — не стоят времени, потраченного на анализ. Вот вам пример от PVS-Studio.
Скажите, сколько своих денег вы готовы заплатить за продукт, который находит такое количество ошибок? Мне вот жалко времени, потраченного на анализ выдачи.
ЧСВ у меня скорее заниженное, компилятор мне об ошибках рапортует ежедневно. Не в этом дело. А в том, что ошибки, найденные станализатором — не стоят времени, потраченного на анализ. Вот вам пример от PVS-Studio.
Скажите, сколько своих денег вы готовы заплатить за продукт, который находит такое количество ошибок? Мне вот жалко времени, потраченного на анализ выдачи.
О, Евгений предсказал это.
Для тех, кто не понял юмор. V501 есть у всех (FreeBSD, Clang, Far, Blender, GCC, Unreal Engine, Chromium, Qt, TortoiseSVN, ...)
Для тех, кто не понял юмор. V501 есть у всех (FreeBSD, Clang, Far, Blender, GCC, Unreal Engine, Chromium, Qt, TortoiseSVN, ...)
Это типичная ошибка мышления. Вы перечисляете верблюдов, созданных комитетом. И уверены, что у всех животных — есть один-два горба. Но не понимаете, что у кенгуру — все иначе. Два члена, переменный срок беременности, если голодает — беременность рассасывается, есть сумка, горбов почему-то нет и так далее…
Вы бы хоть глянули, есть ли эта ошибка в той версии FAR, которую писал Евгений Рошаль лично.
Вы бы хоть глянули, есть ли эта ошибка в той версии FAR, которую писал Евгений Рошаль лично.
Ок, предположим что не детектит (я не в курсе что это за ошибка). Попробуем посчитать ценность детекта.
Возьмем команду в 6 человек, лид, аналитик, 2 дева, 2 QA. 100 евро в час каждый. Цикл разработки: аналитик сидит на клиенте, девы пилят по аналитике, QA тестируют (перед продом и на проде), лид вмешивается при багах.
На проде возникает ошибка из-за V501.
Лид тратит час на косяк (откат\разбор\новый релиз), дев час на анализ\фикс, QA два часа на тесты (один раз когда заметил баг, другой раза когда тестировал фикс).
Итого — потеря в 400 евро. Сценарий пессимистичный.
Оптимистичный сценарий: разраб + QA найдут этот косяк уже на тестовом стенде и пофиксят его в обычном режиме. Потери — 0.
Вероятность пессимистичного сценария — 5%. Оптимистичного — 95%. Мат. ожидание потерь от V501 — 20 евро. А теперь вопрос: сколько V501 случаются в рядовом проекте?
Цифры выше взяты с потолка.
Я видел много статей от PVS-Studio. Видел очень даже неплохие статьи для разработчиков (типа «топ самых популярных ошибок»), но пока еще не видел хорошей статьи с подсчетом выгоды от детектов. Ребята, у вас куча чекнутых проектов. Соберите статистику по частотам ошибок («V123 встречается 0.55 раз в 1000 строк кода»), и у вас появятся хоть какие-то цифры для разговора с менеджерами.
Возьмем команду в 6 человек, лид, аналитик, 2 дева, 2 QA. 100 евро в час каждый. Цикл разработки: аналитик сидит на клиенте, девы пилят по аналитике, QA тестируют (перед продом и на проде), лид вмешивается при багах.
На проде возникает ошибка из-за V501.
Лид тратит час на косяк (откат\разбор\новый релиз), дев час на анализ\фикс, QA два часа на тесты (один раз когда заметил баг, другой раза когда тестировал фикс).
Итого — потеря в 400 евро. Сценарий пессимистичный.
Оптимистичный сценарий: разраб + QA найдут этот косяк уже на тестовом стенде и пофиксят его в обычном режиме. Потери — 0.
Вероятность пессимистичного сценария — 5%. Оптимистичного — 95%. Мат. ожидание потерь от V501 — 20 евро. А теперь вопрос: сколько V501 случаются в рядовом проекте?
Цифры выше взяты с потолка.
Я видел много статей от PVS-Studio. Видел очень даже неплохие статьи для разработчиков (типа «топ самых популярных ошибок»), но пока еще не видел хорошей статьи с подсчетом выгоды от детектов. Ребята, у вас куча чекнутых проектов. Соберите статистику по частотам ошибок («V123 встречается 0.55 раз в 1000 строк кода»), и у вас появятся хоть какие-то цифры для разговора с менеджерами.
Всё просто. Если ошибка стоит 20$, то этому проекту не нужен статический анализатор. Впрочем, это какой-то волшебный проект. В настоящем проекте цена ошибки на порядке выше.
В любом случае, если картина такая, как Вы описали, действительно продать анализатор невозможно. Однако есть другой класс проектов, где ошибка или простой программы выливается в большие деньги. Я, например, знаю случай, когда анализатор PVS-Studio нашел ошибку возрастом в 2 года (там было что-то в духе x*(10/3) из-за которой клиентам автоматически выставлялась неправильная заниженная цена не некоторую группу товаров. Причем, программист рассказал мне по секрету, что побоялись даже доложить начальству об этой ошибке и просто решили втихомолку её исправить.
Еще я знаю случай, когда команду разработчиков несколько раз катали на самолёте на другую сторону земного шара, чтобы они сидели и ждали, когда система опять упадёт, чтобы на месте найти наконец и исправить злосчастный баг, который проявляет себя, как только программисты улетают домой. Оказался неинициализированный член класса.
Я к тому, что ошибки бывают очень дорогие, но при этом до безобразия простые и могли быть легко выявлены анализатором кода. И кстати, менеджеров таких проектов, в отличии от программистов, как-то даже не надо убеждать, что ошибки, это плохо и надо постараться сразу найти их как можно больше.
В любом случае, если картина такая, как Вы описали, действительно продать анализатор невозможно. Однако есть другой класс проектов, где ошибка или простой программы выливается в большие деньги. Я, например, знаю случай, когда анализатор PVS-Studio нашел ошибку возрастом в 2 года (там было что-то в духе x*(10/3) из-за которой клиентам автоматически выставлялась неправильная заниженная цена не некоторую группу товаров. Причем, программист рассказал мне по секрету, что побоялись даже доложить начальству об этой ошибке и просто решили втихомолку её исправить.
Еще я знаю случай, когда команду разработчиков несколько раз катали на самолёте на другую сторону земного шара, чтобы они сидели и ждали, когда система опять упадёт, чтобы на месте найти наконец и исправить злосчастный баг, который проявляет себя, как только программисты улетают домой. Оказался неинициализированный член класса.
Я к тому, что ошибки бывают очень дорогие, но при этом до безобразия простые и могли быть легко выявлены анализатором кода. И кстати, менеджеров таких проектов, в отличии от программистов, как-то даже не надо убеждать, что ошибки, это плохо и надо постараться сразу найти их как можно больше.
Вот в двух описанных вами ситуациях — согласен, статнализ полезен. Вот только цифры бы — насколько часто встречаются именно такие ошибки? Точнее насколько часто по сравнению с другими… Пока что сколько вы не искали в открытых проектах — таких багов вы не нашли.
Что касается второго случая — то это баг архитектуры. Правильно сделанная система АСУТП поднимается после любого бага. То есть она изначально рассчитана на падения.
Что касается второго случая — то это баг архитектуры. Правильно сделанная система АСУТП поднимается после любого бага. То есть она изначально рассчитана на падения.
Кстати, на подобных проектах наверное и компы освящают и ещё много чего делают. Стоит недорого, а вдруг поможет?
Примерно так же 100 лет назад в деревнях сначала шли с подарками к батюшке, а потом к колдуну. Не то, чтобы верили, но вдруг кто-то из них и вправду поможет?
Примерно так же 100 лет назад в деревнях сначала шли с подарками к батюшке, а потом к колдуну. Не то, чтобы верили, но вдруг кто-то из них и вправду поможет?
Кстати, gcc репортит неинициализированные члены класса. Так что этим людям статанализатор не помог бы.
так всё же, у вас не бывает ложноположительных детектов?
UFO just landed and posted this here
С учетом вашей кармы я даже знаю, чем указанием на ваши ошибки закончатся.
Вообще говоря, некто Am0ralist мною плюсанут.
То есть статическим анализатором в команде пользоваться не умеют, окей.
В нашей команде им не пользуются, ибо другой язык. В одной из предыдущих в свое время не удалось показать выгоду менеджеру.
Соответственно, оба сценария из предыдущего комментария рассматриваются в контексте отсутствия стат-ана.
Вывод прост: при использовании статического анализатора удастся сэкономить условные 20 евро на каждой V501. Цифра условная, взята с потолка.
Затраты на обучение персонала — 1100 евро (по часу девам и лиду на ознакомление + 8 часов дева на внедрение в CI и первичную очистку проекта). Цифра условная, взята с потолка.
Итог: ради одной только V501 закупать PVS-Studio невыгодно, штука евро минуса.
Andrey2008 в комментарии выше приводит примеры в духе «Я, например, знаю случай,». С таким бесполезно подходить к менеджеру. Состоится диалог вроде
– От судьбы не застрахуешься, – упорствовал Епишко. – Я вот знаю случай: в грозу человека в чистом поле убило.
– А не лезь в грозу в чисто поле! – обозлился Звягин. – А влез – так держись по низинкам.
Если проект связан с космосом\медициной\серьезными_деньгами\серьезными_исследованиями — там слова «надежность» может и хватить. Если на проект выделены миллионы — просто впишут анализатор как необходимый софт по слову лида. В рядовом проекте задумаются о цене, времени затраченном на внедрение, и поинтересуются выгодой. И менеджеру выгоду проще всего показать в сэкономленных человеко-часах.
Вот только бубен стоит 200-300 рублей, а PVS-Studio — немерянные килобаксы. Стоит ли их тратить на технологию с «недоказанной эффективностью» — непонятно.
Не отпугивайте народ :). Наши цены очень даже скромные по сравнению с Coverity, Klocwork. Мы сознательно выбрали среднюю ценовую нишу и живём в ней. Мы тем, кому PC-Lint уже кажется устаревшим/простоватым/неудобным/не умеющий C++14 (а новый они вот уже 3 года делают на основе Clang, но пока всё никак), а цены на Coverity/Xyz уже перебор.
Причем, в плане диагностик мы уже наступаем на пятки Coverity/Klocwork. Так что соотношение результат/цена весьма привлекательно. Покупайте наших слонов!
Вы случайно самолеты не продавали? А то ну очень аргументация похожа. Ну или антивирусы?
Мне не важно, насколько вы дешевле Coverity. Мне важно, насколько вы лучше бубна и всех остальных плацебо. Причем не просто «мы нашли багов в десять раз больше, чем пляски с бубном». А разница в количестве багов на рубль затрат. Бубен-то я и за 200 рублей купить смогу.
А эффективность доказывается двойным слепым рандомизованным исследованием. Которого у вас нет.
P.S. У меня и резидентный антивирус не стоит (но стоял firewall). И за последние лет 10-15 я отослал в Dr.Web и Касперского немало зверушек. Сказки про то, что без резидентного антивируса сразу комп обрастет вирусами — верны для домохозяйки. Но не верны лично для меня.
Вот и вам совет — узнайте своего пользователя и опишите его. Может и действительно есть такие области, где статанализ выгоднее бубна.
Мне не важно, насколько вы дешевле Coverity. Мне важно, насколько вы лучше бубна и всех остальных плацебо. Причем не просто «мы нашли багов в десять раз больше, чем пляски с бубном». А разница в количестве багов на рубль затрат. Бубен-то я и за 200 рублей купить смогу.
А эффективность доказывается двойным слепым рандомизованным исследованием. Которого у вас нет.
P.S. У меня и резидентный антивирус не стоит (но стоял firewall). И за последние лет 10-15 я отослал в Dr.Web и Касперского немало зверушек. Сказки про то, что без резидентного антивируса сразу комп обрастет вирусами — верны для домохозяйки. Но не верны лично для меня.
Вот и вам совет — узнайте своего пользователя и опишите его. Может и действительно есть такие области, где статанализ выгоднее бубна.
Если честно, то не сталкивался с людьми, возражающими против инструментов статического анализа, проверки/исправления стиля и в принципе строгой проверки ошибок и предупреждений.
Это наверно какой-то пещерный вид для зоопарка и гнать их нужно в шею, т.к. за такой вершиной айсберга скрывается ещё больший пласт проблем: ручные сборки в особо настроенной среде, "секретные знания", собственничество с припадками, удручающее качество кода и отсутствие целостной архитектуры в принципе.
Сталкивался с людьми которые против конкретно PVS-Studio. Аргумент — «задолбали». Он вне бизнес-плоскости, однако лично мне понятен.
я чуть выше написал про бизнес.
А с людьми возражающими против окропления святой водой, вы сталкивались?
«За такой вершиной айсберга» у меня работа системы 365 на 24 в течение 15 лет.
И не путайте божий дар с яичницей. Процентов 50 предупреждений компилятора — это реальные баги, которые надо править. Была бы у статических анализаторов эффективность хотя бы 5% — цены бы им не было.
Кстати, авторы PVS-Studio считают, что в любом проекте при -Wall -Wextra вылезает сотня предупреждений. Если надо — найду вам цитату. У нас почему-то наоборот — ни предупреждений, ни хинтов.
«За такой вершиной айсберга» у меня работа системы 365 на 24 в течение 15 лет.
И не путайте божий дар с яичницей. Процентов 50 предупреждений компилятора — это реальные баги, которые надо править. Была бы у статических анализаторов эффективность хотя бы 5% — цены бы им не было.
Кстати, авторы PVS-Studio считают, что в любом проекте при -Wall -Wextra вылезает сотня предупреждений. Если надо — найду вам цитату. У нас почему-то наоборот — ни предупреждений, ни хинтов.
«За такой вершиной айсберга» у меня работа системы 365 на 24 в течение 15 лет.Не берусь конечно утверждать и не хочу никого обидеть, однако выскажу своё мнение. Когда заходит речь о системах, которые работают 10 лет подряд, то потом выясняется, что речь идёт о весьма и весьма простых программах, которые действительно можно написать без ошибок. Ведь закон экспоненциального роста глючности никто не отменял. А в системах, работающих годами слабый процессор, мало памяти и как следствие маленькие программы. В них часто часто память выделяется только один раз при запуске. Нет выделений памяти и уже нет массы проблем и ошибок.
Процентов 50 предупреждений компилятора — это реальные баги, которые надо править. Была бы у статических анализаторов эффективность хотя бы 5% — цены бы им не было.Процент сообщений анализатора PVS-Studio, с которыми стоит что-то сделать:
- Far — 50%
- PascalABC.NET — 70%
Согласен. Любая надежная система, является простой. Даже если в ней 10 миллионов строк кода и тысяча человек. И наоборот, любая глючная система — сложна, даже если в ней всего пара тысяч строк кода. Вам не кажется, что это аксиома? Более того, мастерство программиста в том и состоит, чтобы сделать максимально простой код.
Глюки, баги (ошибки) и надежность системы — это разные вещи. Глюки — это почти не воспроизводимые ошибки, например — состояние гонки. Статический анализ не помогает их искать. А баги…
Представьте себе, что у вас дом рушится из-за трещины в одном кирпиче. Как нравится? Хочется жить в таком доме? Вот так и мне не нравится пользоваться программами, автор которых решил, что самое главное — устранить все баги. Потому что основное — это обеспечить работу программы независимо от наличия в ней багов.
Ну как пример — OS/360. Там порядка миллиона строк кода и тысяча человеко-лет. При этом она вполне выполнялась на машинах с 200 тысяч операций в секунду и 256 килобайт памяти. Вы считаете, что это небольшая программа? Там только компиляторов пяток был.
Что-то надо сделать с любым сообщением. То есть потратить время, проанализировать код и принять какое-то решение. Реальные показатели этого проекта «плотность будет равна 0.464 ошибки на 1000 строк кода». Это означает, что в FAR остались баги типа «если залезть на шкаф и высунуть в окно телескоп то в коне дома за 3 километра мы увидим голую задницу», А если на шкаф не залезать — не увидим.
И это означает, что правильное решение менеджмента — направить силы не на исправление багов, а на то, что нужно пользователям. То есть на развитие проекта. Или на исправление реальных (проявляющихся у пользователей) багов. Потому что основные баги — они не в кодировании, а в алгоритмах.
Если вам интересны параметры нашей системы, то там 135 тысяч строк и 10 человеко-лет. В серверной част работает два десятка нитей. Теоретическая плотность ошибок — 2-4 ошибки на тысячу строк. Время на комплексную отладку — ноль. Теоретически у нас было два часа в месяц, но мы их не использовали. Количество багрепортов за время промышленной эксплуатации (15 лет) — ноль. Что не означает, что багов там нету. Просто система сделана так, что она надежна несмотря на баги.
Глюки, баги (ошибки) и надежность системы — это разные вещи. Глюки — это почти не воспроизводимые ошибки, например — состояние гонки. Статический анализ не помогает их искать. А баги…
Представьте себе, что у вас дом рушится из-за трещины в одном кирпиче. Как нравится? Хочется жить в таком доме? Вот так и мне не нравится пользоваться программами, автор которых решил, что самое главное — устранить все баги. Потому что основное — это обеспечить работу программы независимо от наличия в ней багов.
А в системах, работающих годами слабый процессор, мало памяти и как следствие маленькие программы
Ну как пример — OS/360. Там порядка миллиона строк кода и тысяча человеко-лет. При этом она вполне выполнялась на машинах с 200 тысяч операций в секунду и 256 килобайт памяти. Вы считаете, что это небольшая программа? Там только компиляторов пяток был.
Процент сообщений анализатора PVS-Studio, с которыми стоит что-то сделать:
Far — 50%
Что-то надо сделать с любым сообщением. То есть потратить время, проанализировать код и принять какое-то решение. Реальные показатели этого проекта «плотность будет равна 0.464 ошибки на 1000 строк кода». Это означает, что в FAR остались баги типа «если залезть на шкаф и высунуть в окно телескоп то в коне дома за 3 километра мы увидим голую задницу», А если на шкаф не залезать — не увидим.
И это означает, что правильное решение менеджмента — направить силы не на исправление багов, а на то, что нужно пользователям. То есть на развитие проекта. Или на исправление реальных (проявляющихся у пользователей) багов. Потому что основные баги — они не в кодировании, а в алгоритмах.
Если вам интересны параметры нашей системы, то там 135 тысяч строк и 10 человеко-лет. В серверной част работает два десятка нитей. Теоретическая плотность ошибок — 2-4 ошибки на тысячу строк. Время на комплексную отладку — ноль. Теоретически у нас было два часа в месяц, но мы их не использовали. Количество багрепортов за время промышленной эксплуатации (15 лет) — ноль. Что не означает, что багов там нету. Просто система сделана так, что она надежна несмотря на баги.
Если вам интересны параметры нашей системы, то там 135 тысяч строк и 10 человеко-лет.Теперь всё понятно. У вас очень маленький проект. И да, в таком проекте использование статического анализатора не является по настоящему нужным: низкая плотность ошибок, возможность обозреть весь проект и осознавать, как он работает.
Числа для сравнения. Весь проекте PVS-Studio мы считаем небольшим. А ядро C++ анализатора PVS-Studio вообще маленьким. Так вот, маленькое C++ ядро PVS-Studio содержит 225884 строк кода.
Это, пожалуй, пограничный размер, когда ещё можно обходиться без статического анализа кода. Мы используем инструменты для анализа своего кода (было бы странно для нас не использовать :). Но повторюсь, процесс развития проекта и его качество ещё можно контролировать вручную. Если же речь о 135000, то тут конечно сложно продемонстрировать полезность инструментов статического анализа.
Ну так об этом и надо было писать в статье! То есть о том, что речь идет о проекта больше 250KLoc.
И все-таки, проверьте гипотезу, что дело не в строках кода, а в количестве девелоперов. FAR 1.65 производства Рошаля не сильно отличается по возможностям от FAR 3.0 (сделанного сообществом). Интересно, насколько он отличается по плотности ошибок.
Зато инструменты динамического анализа полезны при любом размере. Например, у меня там был собственный анализатор утечек памяти. Заодно — они более-менее кроссплатформенны. Тот проект все равно PVS-Studio не проверит, он на Delphi (Object Pascal) был написал.
Нынешний, проверку которого я вам обещал — на С с элементами С++. Но он меньше 50KLoc,
Ну я рад, что мы сошлись. И даже поставил плюс в карму.
И все-таки, проверьте гипотезу, что дело не в строках кода, а в количестве девелоперов. FAR 1.65 производства Рошаля не сильно отличается по возможностям от FAR 3.0 (сделанного сообществом). Интересно, насколько он отличается по плотности ошибок.
Если же речь о 135000, то тут конечно сложно продемонстрировать полезность инструментов статического анализа.
Зато инструменты динамического анализа полезны при любом размере. Например, у меня там был собственный анализатор утечек памяти. Заодно — они более-менее кроссплатформенны. Тот проект все равно PVS-Studio не проверит, он на Delphi (Object Pascal) был написал.
Нынешний, проверку которого я вам обещал — на С с элементами С++. Но он меньше 50KLoc,
Ну я рад, что мы сошлись. И даже поставил плюс в карму.
> Ну как пример — OS/360. Там порядка миллиона строк кода и тысяча человеко-лет. При этом она вполне выполнялась на машинах с 200 тысяч операций в секунду и 256 килобайт памяти. Вы считаете, что это небольшая программа?
Для своего времени (1964) это была очень большая машина. На небольших (с памятью типа 64K) OS/360 могла вообще не идти (были всякие DOS/360 и тому подобные).
> Там только компиляторов пяток был.
Угу. Только вот, например, Fortran G не оптимизировал, а Fortran OE имел столько багов, что непонятно было, как его результат можно вообще использовать. Баги они были и в этой системе.
> Реальные показатели этого проекта «плотность будет равна 0.464 ошибки на 1000 строк кода». Это означает, что в FAR остались баги типа «если залезть на шкаф и высунуть в окно телескоп то в коне дома за 3 километра мы увидим голую задницу», А если на шкаф не залезать — не увидим.
Один баг может создать критическую неработу, а 10000 — не влиять ни на что. При чём тут эти сравнения со шкафом?
> Если вам интересны параметры нашей системы, то там 135 тысяч строк и 10 человеко-лет.
Тут рядом сказали уже, но поддержу — это очень небольшая система, тем более на такое время работы. Даже если считать, что этот объём за половину того времени — то за это время можно было буквально вылизать код.
Для своего времени (1964) это была очень большая машина. На небольших (с памятью типа 64K) OS/360 могла вообще не идти (были всякие DOS/360 и тому подобные).
> Там только компиляторов пяток был.
Угу. Только вот, например, Fortran G не оптимизировал, а Fortran OE имел столько багов, что непонятно было, как его результат можно вообще использовать. Баги они были и в этой системе.
> Реальные показатели этого проекта «плотность будет равна 0.464 ошибки на 1000 строк кода». Это означает, что в FAR остались баги типа «если залезть на шкаф и высунуть в окно телескоп то в коне дома за 3 километра мы увидим голую задницу», А если на шкаф не залезать — не увидим.
Один баг может создать критическую неработу, а 10000 — не влиять ни на что. При чём тут эти сравнения со шкафом?
> Если вам интересны параметры нашей системы, то там 135 тысяч строк и 10 человеко-лет.
Тут рядом сказали уже, но поддержу — это очень небольшая система, тем более на такое время работы. Даже если считать, что этот объём за половину того времени — то за это время можно было буквально вылизать код.
Для своего времени (1964) это была очень большая машина.
А OS/360 и до сих пор — большая система. Хотя характеристики STM32F7 — получше, чем у первых IBM/360. Так что сейчас и на STM32 можно большие системы делать.
Один баг может создать критическую неработу, а 10000 — не влиять ни на что. При чём тут эти сравнения со шкафом?
Вы используете FAR? Если да, то попробуйте найти в нем баги. Традиционный способ ловли ошибок прежде всего вычищает наиболее часто встречающиеся ошибки. А вот статанализ дает почти равный вес и тому, что сработает у 80% пользователей, и тому, что у 0.001%, да ещё и в экзотических условиях использования. Последнее и называется «а вы на шкаф залезьте».
Тут рядом сказали уже, но поддержу — это очень небольшая система, тем более на такое время работы.
Классическая производительность программиста — 10 строк отлаженного процедурного кода в день. Это не означает, что за день нельзя написать 1000 сырого строк. Можно. Только потом ещё 3 месяца (в общей сложности) уйдут на отладку. Так что времени мы потратили в 4 раза меньше, чем нужно по классике.
Вы, наверное, смотрите нормы для объектного кода. Ну да, вместо процедуры на 10 строк на C++ можно написать объект на 100 строк, где 90 будут стандартной обвязкой. Тогда нормы увеличиваются. Мы писали на Delphi. там уместен коэффициент 2-3 относительно классического фортрана.
Что касается вылизывания… Мы с самого начала решили что мы не боги. И ошибки у нас будут. В том числе — и неизвестные нам ошибки. Поэтому вместо вылизывания кода мы сделали так, чтобы система работала независимо от наличия багов. Как «ванька-встанька», которого не положить. Это довольно дорого, по оценке 30% времени ушло именно на поддержку «ваньки-встаньки»…
Если честно, то не сталкивался с людьми, возражающими против инструментов статического анализа,Вот сейчас Вы с ними и познакомитесь. :)
Просьба не передергивать, я не против статического анализа вообще. Тот статанализ, что встроен в gcc и clang — более, чем полезен. А вот цена PVS-studio — не оправдывается той мелочью, что он находит. По крайне мере, если судить об этом по блогу самой PVS-studio. Ну а cppcheck — просто не стоит времени, потраченного на разбор того, что он выдал.
И еще раз повторюсь. Причина ложных срабатывай — отнюдь не баги в коде. Это проблемы алгоритмов. У других проектов — ситуация примерно такая же. Поэтому, если есть лишние деньги — разумней их тратить на развитие.
Признайтесь честно, вы же не купили себе coverity? Хотя некоторое количество багов он бы вам нашел. Вот и другие не хотят покупать примерно по тем же причинам.
И еще раз повторюсь. Причина ложных срабатывай — отнюдь не баги в коде. Это проблемы алгоритмов. У других проектов — ситуация примерно такая же. Поэтому, если есть лишние деньги — разумней их тратить на развитие.
Признайтесь честно, вы же не купили себе coverity? Хотя некоторое количество багов он бы вам нашел. Вот и другие не хотят покупать примерно по тем же причинам.
Мне показалось, что говоря «против инструментов статанализа» автор имеет в виду «против ПВС-студии». Это сильно разные вещи таки.
Прогнал свой личный проект, из 13к более-менее осмысленного кода, реальных ошибок было 3 штуки, ложных срабатываний — около 15 штук. Использовал бесплатную версию. Программистом себя считаю ниже среднего уровня. Тулза особенно полезна на огромных проектах, как я вижу из статей.
Тут ещё штука, смотря что считать ложным срабатыванием. Некоторые называют ложным срабатыванием любой код, который не приводит к реальному багу. К примеру, повторное условие в цепочке OR, которое уже было в той же цепочке. Однако это не ложное срабатывание. Такой код — мина замедленного действия. Завтра надо будет расширять это условие и новый разработчик будет не уверен, действительно ли ветка лишняя и её надо убрать или имелось в виду что-то другое, и её надо оставить. Он потратит время, чтобы разобраться, и может прийти к неверным выводам, внеся новый баг.
В подтверждение ваших слов приведу пример из моего недавнего общения с разработчиком открытого проекта:
Код с ошибкой (бессмысленный код, мина… трактуйте как хотите):
Комментарий разработчика:
Ну нет, так нет. Путь будетложным срабатыванием жить вечно в коде.
Код с ошибкой (бессмысленный код, мина… трактуйте как хотите):
DiscriminantChecks makeDiscriminantChecks(....)
{
....
bool shouldIncludeStructInit =
kind == FieldKind::STRUCT || kind == FieldKind::BRAND_PARAMETER;
bool shouldIncludeSizedInit =
kind != FieldKind::STRUCT || kind == FieldKind::BRAND_PARAMETER; // <=
....
}
Комментарий разработчика:
Thanks for the report.
While it's true that the right-hand side of the expression is redundant, the logic is in fact correct. This happened because when BRAND_PARAMETER was added, all of these booleans needed to be true for it, so || kind == FieldKind::BRAND_PARAMETER was appended to all of them.
Ну нет, так нет. Путь будет
Думаю, что дело в поиске. Если автор кода часто использует поиск — ему удобнее писать именно так, чем
По этим же причинам используются две переменные вместо одной. gcc все равно оптимизирует общие выражения и сделает замену переменных. А вот при поиске по shouldIncludeSizedInit покажутся куски кода, связанные именно с этой функциональностью.
bool shouldIncludeSizedInit = shouldIncludeStructInit;
По этим же причинам используются две переменные вместо одной. gcc все равно оптимизирует общие выражения и сделает замену переменных. А вот при поиске по shouldIncludeSizedInit покажутся куски кода, связанные именно с этой функциональностью.
Тьфу, я неправ, там != во второй строке.
Так что вообще не вижу причин удивляться такому коду. Логика простая. Птицы — это не звери. Но и те и те теплокровные.
Так что вообще не вижу причин удивляться такому коду. Логика простая. Птицы — это не звери. Но и те и те теплокровные.
Тьфу, я неправ
Вот, вот оно! Вы видите! Вы сами можете проморгать в коде существенное отличие в двух строчках! Глаз замыливается. Как же вы можете гарантировать, что никогда не проморгаете такое отличие в своём коде?
Тут как раз статанализ и приходит на помощь. Если б две подряд идущих переменных были бы инициализированы точно одинаковыми условиями, он бы ругнулся на это, а иначе ругается на другое. А варнинги gcc здесь не помогают.
Отличный пост, будем на него ссылаться теперь, особенно при общении с Jef239. :D
Свой код я все-таки пишу, а не только читаю. Опечаток у меня много, но вот такого типа — не припомню. Зато «точка хрения» бывает регулярно.
Методик, которые помогают — много. Вопрос в том, какие из них оправдывают свою цену. В конце концов предупреждения компилятора — это тоже статический анализ. Просто разработчики gcc выбрали набор предупреждений с низким числом ложных срабатываний.
Методик, которые помогают — много. Вопрос в том, какие из них оправдывают свою цену. В конце концов предупреждения компилятора — это тоже статический анализ. Просто разработчики gcc выбрали набор предупреждений с низким числом ложных срабатываний.
Тулза особенно полезна на огромных проектах, как я вижу из статей.
Да, анализатор становится всё полезнее с ростом проекта. Чем больше проект, тем больше плотность ошибок. 13k — это очень маленький проект.
Таблица. Книга Стива Макконнелла «Совершенный код». Размер проекта и типичная плотность ошибок. В книге указаны источники данных: «Program Quality and Programmer Productivity» (Jones, 1977), «Estimating Software Costs» (Jones, 1998).
Таким образом, есть шанс, что в таком проекте вообще не будет ошибок. :)
За что в свое время выбрали зенд студию как пхп-иде — так это за встроенный (хотя и простой) статический анализатор кода. Штука полезная. Но до определенной степени, когда ложных срабатываний накапливается слишком много — разумнее игнорить, чем обращать внимание.
Объяснение для менеджеров: если уборщица получает 5 рублей, ее менеджер получает 25рублей, управляющий ее менеджера получает 30р и программист получает 30р, то среднее (арифметическое) будет 22.5, при этом 75% персонала будет получать зарплату выше средней. А отнюдь не 50%.
В группе из 100 человек 50 всегда будут выше и 50 — ниже среднегоВот точно, статья для менеджеров. Программист или математик сразу увидит неточность (или даже ложность) этого утверждения.
Объяснение для менеджеров: если уборщица получает 5 рублей, ее менеджер получает 25рублей, управляющий ее менеджера получает 30р и программист получает 30р, то среднее (арифметическое) будет 22.5, при этом 75% персонала будет получать зарплату выше средней. А отнюдь не 50%.
Но до определенной степени, когда ложных срабатываний накапливается слишком много — разумнее игнорить, чем обращать внимание.Статический анализатор используется неправильно. Они не должны накапливаться! Полная аналогия с предупреждениями компилятора — их не должно быть. Иначе вступает в силу теория разбитых окон.
Анализатор используется правильно. То что они не должны накапливаться — никто не спорит, но это проблема анализатора и его ложных срабатываний. Наличие которых в анализаторе даже авторы pvs не отрицают.
Но ведь и нет никакой проблему убирать новые ложные срабатывания. По крайней мере, если говорить о PVS-Studio.
Для этого есть масса способов. Например, можно изменить код. При этом как правило он становится проще и понятней, причем не только анализатору, но и коллегам. Очень часто анализатор выдаёт предупреждения на код, который написан в стиле «смотрите, как я могу».
Можно подавлять точечно, используя комментарии. Можно использовать базу разметки. Можно исключить файлы из анализа, если там сгенерированный код или какие-то тесты, аномальные с точки зрения анализатора: if (A == A) для проверки реализации оператора ==.
Для этого есть масса способов. Например, можно изменить код. При этом как правило он становится проще и понятней, причем не только анализатору, но и коллегам. Очень часто анализатор выдаёт предупреждения на код, который написан в стиле «смотрите, как я могу».
Можно подавлять точечно, используя комментарии. Можно использовать базу разметки. Можно исключить файлы из анализа, если там сгенерированный код или какие-то тесты, аномальные с точки зрения анализатора: if (A == A) для проверки реализации оператора ==.
Но ведь и нет никакой проблему убирать новые ложные срабатывания. По крайней мере, если говорить о PVS-Studio.Э.
Во-первых, мы говорили о зенд-студию когда говорили что их накапливается слишком много.
Во-вторых, мы говорили о пхп и об отсутствии проблем с ложными срабатываниями в pvs студию в пхп можно будет говорить не раньше чем pvs студию научится с пхп работать. Кстати, непонятно почему не работает — рынок достаточно большой, задача сравнительно (с уже реализованными) простая.
И если все же выйти из контекста — выше тоже достаточно жалоб на ложные срабатывания именно в pvs студии.
нет никакой проблему убирать: можно изменить код, Можно подавлять точечно, используя комментарии. Можно использовать базу разметки. Можно исключить файлы из анализаНавеяло: «нет никакой проблемы забивать гвозди микроскопом — можно изменить гвозди, можно усилить микроскоп в местах сочленения, можно разметить направление ударов что бы микроскоп не ломался, можно некоторые гвозди не забивать».
Понимаете какая штука, инструмент должен экономить время и работать. А когда разработчик инструмента говорит что «инструмент кривоват конечно, но можно же и самому доработать», то это навязывание обязанностей по принципу «ну тебе че сложно что-ли» совсем не радует. До определённой степени дорабатывать можно, но рано или поздно количество доработок и время на них потраченное начинает превышать выгоду от использования инструмента. Это все же не опен-сорц где получаешь удовольствие от доработки и контрибьюта получив его бесплатно, а платный продукт который должен работать на покупателя, а не наоборот.
Возьмем чуть пример в сторону. Вот есть куча коде-бьютифайеров. Каждый разраб свой нахваливает и говорит что мол «даже если что не так можно настроить», а вот в зенд-студии (вторая причина почему она нам нравится) «коде бьютифайер» работает из коробки без косяков. И? И всё.
UFO just landed and posted this here
То есть код сомнительный пишет разработчик, а кривоват инструмент, который это видит?От оно чё, михалычь.
Т.е. «ложных срабатываний» не бывает, бывает только «код сомнительный».
При чем «сомнительный» по мнению стороннего инструмента (для этого кода и проекта), но инструмент разумеется умнее разработчика, ему лучше знать, сомнительный код или нет.
Я про php и зенд-студию ничего не знаю. Но у меня крутится в голове: быть может у вас просто нормального анализатора не было? :)
Например, мы недавно проверяли проект PascalABC.NET с помощью SonarC# и PVS-Studio. И по нашему мнению, дело обстоит так:
Не будем точно считать проценты ложных срабатываний, так как мнение может быть предвзятым. Но все равно понятно, что осилить 700 сообщений проще, чем 1800. И ясно, что 1800 может сильно утомить и испортить аппетит к статическим анализаторам.
Например, мы недавно проверяли проект PascalABC.NET с помощью SonarC# и PVS-Studio. И по нашему мнению, дело обстоит так:
Не будем точно считать проценты ложных срабатываний, так как мнение может быть предвзятым. Но все равно понятно, что осилить 700 сообщений проще, чем 1800. И ясно, что 1800 может сильно утомить и испортить аппетит к статическим анализаторам.
Я про php и зенд-студию ничего не знаю. Но у меня крутится в голове: быть может у вас просто нормального анализатора не было? :)Может, спорить не будем. Подскажете нормальный?:)
UFO just landed and posted this here
А в Зенд-студии нельзя подавить ложные срабатывания анализатора или гибко его настроить?Можно, но о том и речь, что на определенной стадии количество настроек и подавлений становится выше некоей критической точки.
И если для проекта разрабатываемого «с нуля», это еще куда ни шло (у нас пет проект у зендовского анализатора вопросов не вызывает), то когда входишь в новый проект и надо неделю потратить на настройку — это уже малоинтересно.
При чем очень много логичных, но необычных придирок. Например, перманентно ругается на if(a=5), ему видишь ли надо что бы if(5=a) было, что бы замечания не выдал. Да, мы понимаем причины, но во многих проектах так пишут?
Ну и какой тогда прок от него?Ну определенная польза есть. Просто обидно что для использования на 100% нужно прилагать несоразмерное количество усилий по тюнингу.
(del)
> Полная аналогия с предупреждениями компилятора — их не должно быть.
С чего бы это? Вот компилятор дурак или просто не учитывает моего стиля кодирования, что мне на другой язык переходить?
С чего бы это? Вот компилятор дурак или просто не учитывает моего стиля кодирования, что мне на другой язык переходить?
UFO just landed and posted this here
Штука про то как 90% людей уверено, что их IQ выше среднего.А интернет-опрос показал что 90% респондентов пользуются интернетом.
И ваш пример — явно ложен.Ошибаетесь.
Задача примера была показать что утверждение «В группе из 100 человек 50 всегда будут выше и 50 — ниже среднего»© не является абсолютом, он это показал.
Математик, скорей всего, скучно заметит вам, что распределение зарплат в организации явно не подчиняется нормальному распределению, а вот способности программистов не ограниченных рамками одной организацииАга, так и запишем, распределение способностей программистов ограниченных рамками одного опроса подчиняется нормальному распределению и в опросе «из 100 человек 50 всегда будут выше и 50 — ниже среднего»©
UFO just landed and posted this here
Вы в аналогии вообще никак. Особенно с мат.статом, не ваше это.Если Вы не понимаете аналогию, это не значит что «она никак», это значит что Вы ее не понимаете.
Некорректным «доказательством» не получится ничего показать. Это — логика.Естественно. Именно поэтому был приведен корректный контр-пример, показывающий что есть как минимум одна ситуация, когда заявленное правило не работает. Вы правда этого не поняли?
Вы серьезно? Вообще-то статистику собирают именно так, стараясь, что бы участники опроса подчинялись общему для всех правилу.Вы серьезно? Вообще-то статистику по опросам достаточно редко стараются так собирать (по маркетинговым причинам), а даже когда собирают с прицелом на это то все равно это редко получается — т.к. идеальные условия миф.
Вот если бы вы усомнились в том, что распределение — обязательно нормальное, тогда да.Вообще-то об этом сообщение и было. Жаль что Вы этого не поняли.
Сейчас случайно наткнулся на просторах интернета на интересное обсуждение. В общем, количество предупреждений, выдаваемых PVS-Studio постепенно растет и один неравнодушный замечает, что "It seems that bugfixing is going wrong..." :)
Это я просто на примере хочу ещё раз продемонстрировать, что анализатор может показывать менеджеру о некоторых процессах, происходящих в проекте. Как я писал в статье, анализатор кода это не только инструмент для поиска ошибок, но и один из инструментов для контроля и слежения за происходящим. Он позволяет держать менеджеру руку на пульсе проекта.
Это я просто на примере хочу ещё раз продемонстрировать, что анализатор может показывать менеджеру о некоторых процессах, происходящих в проекте. Как я писал в статье, анализатор кода это не только инструмент для поиска ошибок, но и один из инструментов для контроля и слежения за происходящим. Он позволяет держать менеджеру руку на пульсе проекта.
Видимо, разработчиков этой студии стоит поздравить со взятием еще одной вершины: они так задолбали программистское сообщество своей рекламой (оно реально из каждого утюга сейчас), что когда приходят в любую компанию натыкаются лишь на раздражение. Теперь им приходится аппелировать к менеджерам прямо оскорбляя программистов, утверждая, что 90% их — обладатели синдрома Даннинга-Крюгера, а сами они хорошие. Сам я не программист ни разу (пишу немного на питоне), но даже меня, админа, это задолбаоло.
Как вы оцениваете свой уровень как программиста (ниже среднего, средний, выше среднего)?Настоящий программист спросил бы сначала, как считается среднее?
Среднее среди всех людей?
Среднее среди программистов?
Среднее среди участников конференции по высоконагруженным проектам?
Может быть есть какая-то sensitivity-specificity статистика анализатора в зависимости от настроек?
Или это слишком глубоко?
Или это слишком глубоко?
Не понял вопрос. Прошу уточнить.
sensitivity-specificity — это про ошибки первого и второго рода; про false-positive и false-negative. Всякие статистики-биологи строят ROC-кривые и считают AUC.
Статья точно для менеджеров, так как не содержит ни одного единорога )) У меня знакомый есть, который почти уговорил менеджеров использовать в проектах PVS Studio, как те зашли на ваш сайт и сказали, что какие-то несерьезные ребята
В продолжении этой темы: Простая ошибка при кодировании — не значит нестрашная ошибка.
Sign up to leave a comment.
Статья о статическом анализе кода для менеджеров, которую не стоит читать программистам