Статья о статическом анализе кода для менеджеров, которую не стоит читать программистам

    Что нам делать с ошибками?

    Если вы считаете себя хорошим программистом, ну, скажем так, вы оцениваете свой уровень выше среднего, прошу не читать эту статью. Эта статья предназначена для менеджеров программных проектов. С ними я хочу обсудить хотя и важные, но скучные для программистов вопросы, связанные с методологией статического анализа кода.

    Надеюсь, введение отпугнуло от чтения хотя бы некоторых программистов. Кто-то, наверное, из принципа продолжил чтение, но что ж, это их добровольный выбор. Мы поговорим о вещах, которые неприятны программистам.

    Наша компания занимается разработкой анализатора PVS-Studio, предназначенного для поиска ошибок в коде программ на языке C, C++ и C#. Идея проста: запускаем регулярно анализатор и изучаем участки кода, которые показались ему подозрительными. В общем, некий аналог автоматического code-review.

    Любому менеджеру, да и самим программистам понятно, что качественный код лучше, чем некачественный. Понятно и то, что чем реже в программе проявляются глюки, тем лучше.

    Самое интересное начинается дальше. Хотя все признают важность качественного кода, некоторые программисты приходят просто в негодование, когда им предлагают использовать статический анализ кода. Такое впечатление, что их оскорбили, усомнившись в их профессионализме, и они спешат ответить всем арсеналом своей негативной критики. За годы мы услышали огромное количество нелестных отзывов, приблизительно следующего содержания:

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

    Думаю, если бы в момент таких дискуссий рядом присутствовал менеджер проекта, то немало программистов получило от него щелбан за гордыню. Каждый руководитель может вспомнить, как несколько дней искали ошибку, которая потом оказалась какой-то глупой опечаткой. Или менеджера может начать одолевать скепсис: если все так всё хорошо, почему приложение продолжает падать время от времени? Менеджеры не так радужно, как программисты, относятся к процессу разработки проекта и возникающим проблемам.

    Рисунок 1. Программисты часто слишком оптимистичны, будучи уверенными, что всё прекрасно.


    Рисунок 1. Программисты часто слишком оптимистичны, будучи уверенными, что всё прекрасно.

    Поэтому я хочу раскрыть менеджерам тайну, которая на самом деле, конечно, никакой тайной не является. У программистов есть проблема с переоценкой своего уровня. Про это хорошо написано в статье "Программисты 'выше среднего'" (en). Процитирую отрывок:

    Как вы оцениваете свой уровень как программиста (ниже среднего, средний, выше среднего)?

    Согласно психологическим опросам среди разных групп, около 90% программистов отвечают «Выше среднего».

    Очевидно, это не может быть правдой. В группе из 100 человек 50 всегда будут выше и 50 — ниже среднего. Этот эффект известен как иллюзия превосходства. Он описан во многих областях, но даже если вы об этом слышали, вы всё равно, вероятно, ответите «выше среднего».

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

    Анализатор PVS-Studio находит ошибки в коде таких проектов как Qt, MSBuild, LLVM, GCC, GDB, Chromium. Разработчиков этих проектов никак нельзя оценить ниже среднего. Однако, это не мешает все новым и новым программистам отвечать, что их код качественен и для них анализ кода не актуален. Я в таких случаях люблю спрашивать: раз все кругом так хорошо и все такие профессионалы, то кто сделал вот эти 11000 ошибок? Вопрос, конечно, риторический, и я не жду ответа.

    Думаю, менеджеры понимают к чему я клоню. Статический анализ крайне важен и полезен при разработке средних и больших проектов. Он помогает бороться со многими ошибками и позволяет контролировать качество процесса разработки в целом. Регулярные проверки позволят вовремя выявить аномальный рост количества ошибок, связанный, например, с тем, что кто-то собрался увольняться и говнокодит, так как ему уже все равно, но надо создавать видимость работы. Эту ситуацию я, конечно, придумал, но действительно полезно иметь инструмент, который может оценить насколько с проектом всё хорошо, и количество предупреждений анализатора — одна из лучших для этого метрик.

    Кстати, на эту тему расскажу кое-что интересное. Недавно коллега проверял проект CryEngine V. Баг на баге. Коллега даже не досмотрел предупреждения уровня High, уж очень их много. А потом мы вдруг узнаем, что в последнее время у компании Crytek проблемы и некоторые программисты уже 3 месяца не получают зарплату. Нездоровая ситуация в компании отразилась на качестве кода. Интересно было увидеть такую явную взаимосвязь.

    В общем, надо не стесняться заставлять программистов использовать статический анализ кода. Пусть даже не PVS-Studio, пусть это будет хотя бы Cppcheck (выполняет простые проверки, но зато бесплатен). Это уже будет большим хорошим делом. Программист, конечно, может капризничать, поэтому стоит проявить твердость.

    Часто программисты ссылаются на то, что работа с анализатором отнимает время, заставляя просматривать ложные предупреждения.

    Здесь я не сдержусь от сарказма: Да, да… Потратить один день на настройку анализатора, чтобы сократить количество ложных срабатываний, это много. А сидеть и неделю искать ошибку, это в самый раз, это нормально.

    Proof: ошибка, на обнаружение которой было безуспешно потрачено около 50 часов, при помощи однократного запуска анализатора была обнаружена и исправлена менее чем за час.

    Кстати, если нет нужды начать с поиска ошибок в старом коде, то интегрировать в процесс разработки статический анализатор очень просто. PVS-Studio может показывать ошибки, относящиеся только к новому или измененному коду (см. массовое подавление сообщений анализатора).

    Следует скептически относиться к возражениям программистов на тему того, почему им не нужен статический анализатор. Им-то, может, он действительно не нужен. Он нужен проекту. Эта одна из методологий, такая же как, например, юнит-тесты, которая позволяет повысить надежность программы и, тем самым, сократить траты на её сопровождение. Чем быстрее какие-то ошибки будут найдены, тем лучше. Статические анализаторы позволяют выявлять ошибки на самом раннем этапе, т.е. сразу, как только они появятся в коде.

    Рисунок 2. Учтите, некоторые программисты используют статический анализ неправильно.


    Рисунок 2. Учтите, некоторые программисты используют статический анализ неправильно.

    Ещё один важный момент. Некоторые программисты могут заявить, что при тестовом прогоне ошибок найдено мало, поэтому внедрение анализатора кода нецелесообразно. Не дайте им себя запутать. Конечно, ошибок в отлаженном и работающем коде будет немного, иначе бы программа не работала. Однако, поиск и устранение ошибок может обходиться очень дорого. Часто многие жалобы пользователей и часы медитации программистов в отладчике могли бы просто исчезнуть, благодаря одному запуску анализатора кода. Вся суть и польза статического анализа в его регулярном применении, а не разовых запусках.

    Несколько раз я сам слышал, что некоторые программисты запускают статические анализаторы при подготовке к релизу. Если кто-то так делает и утверждает, что это нормально, то он профнепригоден. Это самый неправильный способ использования статических анализаторов. Это то же самое, что включать перед релизом предупреждения компилятора, а все остальное время работать над проектом, полностью их отключив.

    Спасибо за внимание. Приглашаю всех, кто заинтересовался методологией статического анализа в целом и анализатором PVS-Studio в частности, написать нам. Мы поможем проверить ваш проект, настроить анализатор, и подскажем, как разобраться с выданными предупреждениями.


    Если хотите поделиться этой статьей с англоязычной аудиторией, то прошу использовать ссылку на перевод: Andrey Karpov. A post about static analysis for project managers, not recommended for the programmers
    PVS-Studio
    773,00
    Static Code Analysis for C, C++, C# and Java
    Поделиться публикацией

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

      +5
      По моему опыту, те программисты которые не любят статический анализатор в основном банально редко его запускают из-за чего возникает множество ложных срабатываний.
        +6
        Есть еще такие, которые не любят, хотя и ни разу не запускали :-).
          +1
          Так оно и есть. К сожалению, для индустрии, многие никак не могут осознать, что вывод анализатора нужно держать чистым. А ведь это уже давно описано, разобрано и обсуждено для предупреждений компилятора. Когда накапливаются предупреждения компилятора, люди перестают их читать, они перестают помогать, а только мешают. Именно отсюда растут ноги у ключей компилятора, заставляющих интерпретировать предупреждения как ошибки.

          Но воз и ныне там. Мы проверяем много проектов и видим, что при компиляции многие проекты страдают «недержанием предупреждений». При компиляции выводятся сотни warnings.

          Собственно, та же самая картина и с анализаторами кода. И, опять-таки к сожалению, часто только менеджер может изменить ситуацию. Используя административные рычаги, он может заставить не оставлять варнинги и внедрять анализаторы. Вот так и живём.
            0
            Собственно, та же самая картина и с анализаторами кода. И, опять-таки к сожалению, часто только менеджер может изменить ситуацию.

            Обычно как раз менеджер и является причиной


            Но воз и ныне там. Мы проверяем много проектов и видим, что при компиляции многие проекты страдают «недержанием предупреждений». При компиляции выводятся сотни warnings.
          +2
          А что в этой статье может не понравиться программистам?
            +9

            Мне вот тоже непонятно. Если есть инструмент, который за тебя прошерстит код и укажет на подозрительные или очевидно ошибочные места, это же круто. Конечно, искать и исправлять ошибки бывает интересно, но если программист не нашёл их сразу, видимо, они неочевидные или редко срабатывающие, что повышает их опасность в разы. А не ошибается, как известно, только тот, кто ничего не делает.


            Странно, что среди разработчиков есть такие самоуверенные люди, которые думают, что пишут идеальный код. Они вообще ни одной популярной большой программой не пользовались, что ли? Везде полно багов и дыр, и в ОС, и в браузерах, и в прочем прикладном софте. Считать себя на голову круче всех тех, кто пишет операционки и браузеры, могут разве что совсем неопытные программисты. Ну и эффект Даннинга-Крюгера забывать не стоит. Я вот свой уровень оценил бы как средний или ниже среднего, и чем больше узнаю, тем ниже этот уровень оцениваю.

              +5
              Странно, что среди разработчиков есть такие самоуверенные люди, которые думают, что пишут идеальный код.

              Добро пожаловать в реальный мир программирования. :) Думаю, дискуссия которая разворачивается, будет Вам необычно и интересна.
                +1
                Добро пожаловать в реальный мир программирования.

                В соседних темах люди жалуются на то, что их приглашают на собеседование программистом. И, ужас — просят пузырёк(!) на бумажке карандашиком изобразить(!). Какая нафиг «алгоритмическая база», они-то получили сертификат FOO и хотят творить мир в сооветствии с BAR :-)

                Не говоря уж о том, что в их IDE есть кнопка «Debug» не догадываются вовсе…
                  0
                  Ну а какая практическая польза в такой задаче на собеседовании?
                    0
                    Вы не поверите, но очень даже практическая: отсеять тех, кто решил что имеет какое-то отношение к профессии.
                      0
                      На практике же — 90% из тех, кто помнит метод пузырька, его и будут использовать при необходимости написать сортировку. Прикола ради задали вопрос по пузырьку студенту стажеру. Нарисовал правильно. А он, на минуточку, человек, который пишет код уровня:
                      if (x === true) {
                          toggle(true);
                      } else if (x === false) {
                          toggle(false);
                      }
                      
                        0
                        А что там помнить-то в этом методе?
                        Половина алгоритма уже содержится в названии.
              +1

              Они почему-то уверены, что статический анализатор неприятен всем программистам:


              Мы поговорим о вещах, которые неприятны программистам.
              Наша компания занимается разработкой анализатора PVS-Studio, предназначенного для поиска ошибок в коде программ на языке C, C++ и C#. Идея проста: запускаем регулярно анализатор и изучаем участки кода, которые показались ему подозрительными. В общем, некий аналог автоматического code-review.
                +3
                Это называется гипербола (стилистическая фигура явного и намеренного преувеличения, с целью усиления выразительности и подчёркивания сказанной мысли). Конечно не всем, но мы видим что это действительно есть, и даже в обсуждении этой статьи. Поэтому и захотелось обратить внимание на этой читателей. И мне кажется, это удалось и завязывается интересная дискуссия.
                  0
                  Не скажу за плюсы и шарп, ибо не настолько в теме. Но что касается C — использование и таких анализаторов, и valgrind с аналогами, и чего-то вроде ebizzy, это очевидность. Не очень понятная, впрочем, тем, для кого C всего лишь исторический факт :-)
                    +2
                    Я за C++ скажу. По моему субъективному мнение (а в этом вопросе мне можно доверять), разницы между качеством кода C и C++ нет. И там, и там есть опечатки и и.д. Да, в C++ стало лучше с управлением памяти, зато и способов накосить стало больше. Например, можно написать std::unique_ptr p(new A[3]);. Т.е. выделяем массив, а уничтожаем потом как один элемент.

                    Иногда попадаются очень качественные C++ проекты, написанные на всяких контейнерах, с применением всяких хороших техник и т.п. И там очень сложно найти ошибку (пример). Но так ведь есть и очень качественные C проекты (пример).
                      0
                      Да, в C++ стало лучше с управлением памят

                      По молодости и глупости :) когда я не смог разобраться с одной утечкой, которая проявлялась в зависимости от фазы луны, и обрушивало приложение, пришлось открыть для себя вот. Потом проблему нашли, выявили, и грубым способом устраняли ещё пару месяцев, потому что затычка — не решение, а оно тянуло за собой ещё много переписывания кода.

                      (если коротко — возврат локальной переменной где-то в глубине «си с классами», но это столько за собой потянуло, и столько выявило… плюс на это наложилась куча опечаток типа "=" vs "==", что сами фигели как это вообще работало )
                        0

                        Лямбды теперь тоже добавляют веселья. У меня вот на днях было: цикл по коллекции, в нём значения из коллекции передаются в лямбду, захват по ссылке, но работает криво — или выдаёт неверные значения, или падает. Потом оказалось, что лямбда выполняется вообще в другое время, а то и в другом потоке, когда переменная цикла уже давно уничтожена. А по виду функции, которая принимает лямбду, не всегда можно сказать, синхронное там выполнение или нет, надо ли учитывать время жизни передаваемых объектов или лучше просто копировать их.

                        +1

                        Интересно, что в качественной Касабланке всё равно нашлись и опечатка копипаста, и как раз упомянутая некорректная инициализация умного указателя, а также некорректное освобождение умного указателя.

                    +2
                    А что в этой статье может не понравиться программистам?

                    См. комментарии ниже. :)
                      +3
                      Два хейтера внизу (обратите внимание на карум оных), один даже успел передернуть в подсчетах и некорректно посчитал «упущенную» выгоду строго под свои измышления в качестве «доказательства».

                      Собственно, на хабре, такое ощущение, уже прям сложилась группа лиц, которые готовы докапываться к чему угодно от оной компании.
                      –7
                      Попробуйте заменить «статический анализ» на «статическая типизация». Ничего не поменяется. Разве что прикрутить к существующему языку статическую типизацию внешними средствами сложнее. А трейдофы практически такие же.
                        +8
                        Интересное мнение. Чем-нибудь подкреплено?
                        А то для указанных языков типизация то статическая, а анализатор зачем-то используется.
                          0
                          Так они не пересекаются, вот и используют оба. А с практической точки зрения очень похоже: тебе надо постоянно подсказывать компилятору (статическая типизация) или анализатору (статический анализ), что ты имел в виду. Потому что вывести самостоятельно они это не могут. Это постоянная работа, которая требуется здесь и сейчас. За это возникает вознаграждение когда-нибудь потом, по мере обнаружения ошибок.

                          Соответственно, все претензии, которые высказываются к статическому анализу — «зачем нам делать лишнюю работу сейчас», можно предъявить и статической типизации.
                          –8
                          Лучше замените «статический анализ» на «окропление святой водой» или «битье в шаманский бубен». Эффективность на рубль затрат будет примерно та же. Хотя… наверное у каждого айтишника были ситуации, когда помог именно бубен. Кто-то и ракеты перед стартом освящает.

                          PVS-studio пока не проверял, а CPP-check… Эффективность близкая к нулю. За 3 дня разбора — ничего существенного. При этом варнинги компиляторов — примерно процентов 50 — это реальные ошибки. Хинты компиляторов — процентов 10 указывают на ошибку.

                          Вот только бубен стоит 200-300 рублей, а PVS-Studio — немерянные килобаксы. Стоит ли их тратить на технологию с «недоказанной эффективностью» — непонятно.
                            +3
                            Вот про это и статья…
                              –5
                              Увы, весь ваш бог — это антиреклама PVS-studio. Судя по вашему блогу, реальные, мешающие пользователям ошибки PVS-studio помогает исправлять намного реже бубна. ВО всем вашем блоге — 1-2 примера про то, что у человека был реальный баг, он запустил PVS-studio и баг нашелся. Зато — примеров про полезность бубна — сотни.

                              Зато — цена статического анализа — намного больше цены бубна. Дело не только в стоимости, но и во времени выполнения и анализа. В основном — анализа. И это касается не только ложных срабатываний. Но и вполне реальных, но десятой степени важности. Потому и запускают бесплатный cppcheck редко, что затраты на его запуск не оправдываются. Максимум — проверить перед релизом, что мин нет.

                              Зато — никто не пишет в комментариях «спасибо, мы за этим багом год гонялись». Основная реакция — «извините, у нас есть реально важные вещи. Те мелочи, что вы нарыли — мы когда-нибудь исправим». И это — главная антиреклама статического анализа.

                              Причина простая: основные баги — в алгоритмах. В работе аналитиков. математиков. постановщиков, алгоритмистов. А багов при кодировании — не так много.

                              Отдельный вопрос про уязвимости. Ну в общем ваш представитель сам признал, что пока что примеров нахождения реальных, эксплуатируемых уязвимостей у вас нет. Но как раз тут вам может повезти.

                              А основной эффект от статического анализатора — это введение в заблуждение менеджеров. «Раз мы потратили килобаксы — значит наш код будет без ошибок». Это в принципе неверно, потому что большинство ошибок — алгоритмические. Статический анализ, бубен, окропление святой водой — все это плацебо. Да, немного помогает. Но зато — оттягивает время на реально полезные меры. Те, что дают эффекта намного больше стоимости.
                                +4
                                основные баги — в алгоритмах. В работе аналитиков. математиков. постановщиков, алгоритмистов. А багов при кодировании — не так много
                                Да неужели?

                                Зачем вы постоянно выделяете рандомные куски фраз жирным? Такое ощущение, что вы периодически на крик срываетесь
                                  –1
                                  Это смысловое ударение. Жирные слова говорятся с нажимом. А вы знаете более лучший способ их передать? Или вообще против rich-text?
                                    –2
                                    Если вы читаете главными баги при кодировании, то советую подумать о том, являются ли баги при кодировании причиной ложных срабатываний PVS-studio. Или почитать соответствующую статью от авторов.
                                    +2
                                    ВО всем вашем блоге — 1-2 примера про то, что у человека был реальный баг, он запустил PVS-studio и баг нашелся.
                                    Ну что делать, если нам редко сообщают об интересных найденных ошибках. Да и о большинстве мы всё не можем написать. Почти у всех наших клиентов код закрыт, и они не хотели бы чтобы мы приводили примеры из их кода. Не писать же статью в духе. Компания X нашла ошибку, Y, в коде Z, но X/Y/Z мы не покажем. :)

                                    Косвенным подтверждением эффективности анализатора и что он находит серьёзные ошибки, является то, что многие компании год из года продлевают лицензии. Это Жжжж не с проста.

                                    Потому и запускают бесплатный cppcheck редко, что затраты на его запуск не оправдываются.
                                    Запускайте что-то посерьезней и поудобней. Например, можно настроить PVS-Studio чтобы он запускался ночью и отправлял письма тем, в чьём коде нашлось подозрительное место. Очень удобно.

                                    Причина простая: основные баги — в алгоритмах. В работе аналитиков. математиков. постановщиков, алгоритмистов. А багов при кодировании — не так много. А основной эффект от статического анализатора — это введение в заблуждение менеджеров.
                                    Большое спасибо за ваш комментарий. Благодаря ему моя статья становится что ли более достоверной. А то получается, что я описываю неких абстрактных людей. А Вы как бы воплощаете заблуждения в реальность. :)
                                      –2
                                      А вы свой код не проверяете разве? Пока что вы дали только антирекламу: "Мы тут проверили свой код и нашли ерунду". И это полностью соответствует моим ощущениям от cppcheck.

                                      Возьмите любое ложное срабатывание. И оцените — сколько процентов — не исправимо в принципе, сколько — отсутствие функциональности, сколько — ошибки алгоритма, сколько — ошибки в коде, не находимые статанализом, и сколько ошибок на самом деле нашел статанализатор во время разработки.

                                      Возьмите статистику по тестированию. У вас в посте рассказано про 7 методик тестирования. Оцените, какой процент ошибок находится именно статанализом.

                                      Сделайте двойное слепое рандомизированное исследование. Насколько статанализ уменьшает количество ошибок? И насколько он лучше плацебо?

                                      Косвенным подтверждением эффективности анализатора и что он находит серьёзные ошибки, является то, что многие компании год из года продлевают лицензии. Это Жжжж не с проста.

                                      Я рад, что вы тоже читали про жопу Хэнка. В ответ могу сказать, что бубен используется даже на атомных электростанциях, а сбербанк освящает отделения.

                                      Как и любое целование жопы Хэнка, бубен дает как минимум плацебо-эффект. Вопрос лишь в том, что на тысячу рублей затрат эффект от бубна намного больше, чем от статанализа. Если вы знаете условия, при которых эффект от статанализа выше, чем от бубна — то честно опишите их.

                                      Например, можно настроить PVS-Studio чтобы он запускался ночью и отправлял письма тем, в чьём коде нашлось подозрительное место. Очень удобно

                                      У вас есть способ по номеру строки и имени модуля автоматически найти комит, который внес ошибку? Или вы хотите просто отправлять тому, кто последний раз правил данный кусок? Первое — очень интересно. Особенно, если там не банальный bisect, а что-то умное.

                                      А Вы как бы воплощаете заблуждения в реальность. :)

                                      Если вернее — мои заблуждения совпадают с вашей антирекламой. Если бы вы написали: "У нас тут плагин выпал из станализа, в итоге там было 100500 ошибок, мы выпустили плагин на год позже и он до сих пор глючен как тупайя" может быть я и поверил бы. Но вы написали честно.

                                      А вот и ещё подтверждение. Опять ваша статья о ложных срабатываниях. И вы опять честно говорите, что дело в алгоритмах, а не в багах в коде. И ни один супер-пупер анализатор не поможет вам уменьшить число ложных срабатываний — для этого все равно нужно развивать алгоритмы.

                                      Возможно, есть некоторая узкая область, где статанализатор оправдывает свою цену. Но тогда нужно просто её описать. Как вариант — это веб-проекты, где действительно ошибка может стать уязвимостью.
                                        +1
                                        Вы усиленно ссылаетесь здесь и в других комментариях на статью "Проверяем исходный код плагина PVS-Studio с помощью PVS-Studio" и говорите «ага, я же говорил, что мало находится». Есть 3 момента, о которых Вы не подумали или сознательно не замечаете.

                                        1. Плагин для Visual Studio, это маленькая программа, там просто негде взяться сотням ошибкам.
                                        2. В маленькой программе и плотность ошибок меньше.
                                        3. Суть статического анализа в регулярных запусках. Мы бы возможно сократили время на поиск некоторых ошибок, если использовали анализатор сразу. Но для такой маленькой программы как плагин об этом и рассуждать особенно смысла нет. Можно вполне обходиться без статического анализа, что мы и делали. Эта статья писалась не для рекламы, а исключительно для того, чтобы наконец было отвечать на вопрос, который уже вызывает зубную боль, проверяли ли мы PVS-Studio с помощью PVS-Studio.
                                          –5
                                          Да почему же, замечаю. Маленькая — это по вашему сколько строк? То есть с какого размера программы PVS-Studio начинает оправдывать свою цену? Это первый важный вопрос.

                                          По моему мнению, маленькая — это программа, написанная малой группой, где тимлид лично читал весь код и помнит его наизусть. В ней может быть и полмиллиона строк кода — тут дело не в размере. С другой стороны, программа в 10 тысяч строк, которую писал десяток авторов — это большая программа (тот самый верблюд, что создан комитетом вместо лошади) и в ней багов будет порядочно. Особенно, если куча авторов делали лишь несколько комитов, то есть не разбирались в коде достаточно долго.

                                          Ну вот вам другая ваша же статья. Выбрана ровно потому, что это детище одного автора (или малой группы). Да, что-то нашлось. Но найденное — явно не соразмерно цене PVS-Studio.

                                          А второй вопрос, это не лучше ли вместо покупки статанализатора купить бубны, освятить компы, покрасить стены в зеленый цвет или сделать какие-то ещё плацебо-мероприятия. Потому что любое плацебо — немного помогает. При каких условиях PVS-studio выгодней бубна, если считать на рубль затрат?

                                          А знаете, как работают там, где цена ошибки — 35-40 тысяч долларов? Там премия равна окладу. А снимается премия со всей службы за 3 часа простоя в месяц. Итог - ноль минут простоя за 3 года, что я отслеживал установленную там нашу систему. И опять вопрос — при каких условиях выгоднее платить за PVS-studio вместо премий (той же суммой) разработчикам?

                                          Кстати, примитивный статанализ я там написал, но применять его не стали. А вот динамический анализ хорошо пошел. Динамический анализ по аварийному сигналу определял, срабатывание какого датчика вызвало аварию. Определялось верно в 99.7% случаев, ложных срабатываний — меньше 0.1%. Ну то есть меряли на 1000 сэмплов и не нашли.

                                          Это некоторый намёк — программа (плагин к отладчику), которая при возникновении исключения находит ошибку — может быть безумно популярной при её разумной цене. Ну и ложных срабатываний в ней немного.
                                            0
                                            А знаете, как работают там, где цена ошибки — 35-40 тысяч долларов? Там премия равна окладу.

                                            Не обсуждая то, что это в принципе незаконно, у руководителей этой организации зарплату тоже режут, если сотрудники допустили баг в программе?

                                              0
                                              Премию снимают со всей службы, включая руководителя службы. Правда, службы у них маленькие, до десятка человек в службы. Насчет Мордашова — не знаю. Думаю, у него дивиденды намного больше оклада.

                                              А вот про «незаконность» — расскажите. Очень интересно аргументацию послушать.
                                              +4
                                              Не вы случайно писали статью о российских ракетах, на которые официально тратится ~130000 рублей на освящение церковью?
                                                0
                                                Нет, я всего лишь дал на неё ссылку. Сбербанк делает и то и то — и PVS-Studio покупает и отделения освящает. Похоже, что это явления примерно одного порядка полезности.
                                                  0
                                                  Псс, парень, где здесь тех. отдел?


                                                +6
                                                Слушайте, я вас не понимаю. Ну не нужен вам их продукт, считаете его слишком дорогим, бесполезным и т.д. — не покупайте, не используйте и вообще всячески игнорируйте. Я постоянно читаю этот блог, и постоянно вижу, как вы бегаете по статьям, чтобы рассказать, как вам PVS-Studio безразличен, что он нафиг не нужен, что вообще вы ненастоящий программист и вот это всё. Какой в этом смысл? Не хотите — не используйте. А то сейчас выглядит так: то ли вы просто хейтер, то ли вы всячески демонстрируете свою «нетаковость» и олдфажность, то ли вам очень хочется юзать PVS, но давит жаба, и поэтому вы компенсируете вот таки странным образом. В заключение цитата из Остера:
                                                А кому смотреть противно —
                                                Тот пускай и не глядит.
                                                Мы же в нос к нему не лезем —
                                                Пусть и он не пристает.

                                                И цитата из ФИДО:

                                                «Отпишись и не читай!»
                                                  –6
                                                  Может вы ещё и уголовное дело за оскорбление чувств верующих в PVS-studio возбудите? :-)

                                                  Я откомментировал всего 2-3 статьи, то есть меньше 1% статей в блоге PVS-studio. Это вот четко показывает, что ваше отношение к PVS-Studio — религиозно, а критическое мышление у вас отсутствует как класс. В чем-то это даже верно — статанализ надо рассматривать наравне с бубном и другими суевериями. См. замечательную статью про Hype Driven Development

                                                  А добился я пока одной честной цифры — меньше 250 KLoc любой статанализ «не обязателен».

                                                  Думаю, что добьюсь и остальных цифр, например, с какого размера программы окупается цена PVS-studio, каков экономический эффект и так далее. То есть того, что реально нужно знать до покупки.

                                                  Ну а вы — можете и дальше верить, что любая модная технология применима всегда и везде.

                                                    +4
                                                    Это очень оригинально — умудриться в моих словах о нелогичности вашего поведения найти религиозную веру и еще кучу вещей, которых там и близко не было. Впрочем, я благодарен вам вот за вот эту фразу:
                                                    Статанализ надо рассматривать наравне с бубном и другими суевериями
                                                    Таким образом, у вас тут религиозный поход против статанализа, как бы вы не изворачивались, утверждая обратное. Чудно, теперь все встало на свои места. Продолжайте писать ваш супербезгрешный безошибочный код и дальше да считайте статанализ модной фигней, которой при царе Горохе-то не было и ничего, жили как-то.

                                                    ЗЫ:
                                                    [offrop]
                                                    ваш плевок мне в карму воспринимаю исключительно как как ваше бессилие в попытках внятно аргументировать, чего вам так не нравится в PVS и статанализе вообще. Засим откланиваюсь, потому как вести с вами конструктивный диалог явно не выйдет (по причине религиозной веры, таки да, только вот чьей — боооольшооой вопрос).
                                                    [/offtop]
                                                      –2
                                                      В PVS мне не нравится цена, а в модных технология вообще — попытка выдать очередную модную фишку за панацею. Что и было написано не менее пяти раз.

                                                      Любая технология чуть ли не половину эффекта дает до своего реального внедрения. Это собственно плацебо (или почти плацебо). Не важно, красите ли вы стены в зеленый цвет, раздаете сотрудникам бубны, устанавливаете теннисные столы, освящаете кабинеты или внедряете статанализ — какой-то эффект будет всегда.

                                                      Есть подозрение, что основной эффект от статанализа — это всего лишь мотивация сотрудников. «Ой. руководство решит, что у меня багов много, буду-ка я писать аккуратней». Беда в том, что замотивировать можно и меньшими деньгами, чем плата за PVS-studio.

                                                      Теоретически статанализ полезен, но самые полезные 9% статанализа встроены к компилятор. Все остальное — это гонка за оставшимися 3-5 процентами. Стоит ли платить немалые деньги просто за собственный перфекционизм — это большой вопрос.

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

                                                      Ну должен же быть среди толпы модников хоть один взрослый, понимающий, что это всего лишь мода и она пройдет?

                                                      +2

                                                      Безотносительно от PVS-studio (для java его нет и вряд ли в обозримом времени появится) — стат.анализ помогает даже в условно-мелких проектах. На своём примере знаю, что применение стат. анализа помогло:


                                                      • идентифицировать несколько багов, могущих испортить выводимые данные в многопоточном окружении (к сожалению базовая библиотека форматированного вывода даты в Java непригодна к использования в многопоточном окружении, т.к. использует общий объект с внутренним состоянием)
                                                      • увидеть несколько опасных мест, которые в ряде случаев могли сработать в виде багов
                                                      • увидеть места, которые можно было упростить (чем повышалась читабельность).

                                                      Сколько это в деньгах — сказать не смогу, не менеджер. Но в любом случае в цену багов входят не только стоимость работы девов/qa, но и репутационные издержки, а в некоторых случаях — и прямые финансовые потери ($440 000 000, помог ли бы им стат. анализ неизвестно, о таких фейлах наружу инфу стараются не выпускать, но вероятность такого исхода была бы всё же ниже).


                                                      PS и да, согласен с Ахриманом — ваше хейтерство PVSов сильно похоже на религозное мракобесие… успокойтесь уже. Не нравятся они вам — забейте и не смотрите их стати.

                                                        –3
                                                        Знаете, при риске в 440 миллионов, я бы не только освятил проект. Но ещё и позвал бы муллу, равина и ламу. Ну и настоящего шамана — это уж само собой.

                                                        Но граница выгодности — это как раз самый интересный момент. И когда о нем умалчивают — появляется желание объяснить толпе малолеток молодежи, что эта граница есть. Благо большая часть хабра годится мне в дети.

                                                        А про ваш проект мне интересен другой вопрос. Сколько времени вы потеряли на проверку результатов статанализа и сколько бы стоили те фичи, которые бы вы смогли за это время написать? Ну или сколько реально проявляющих багов могли бы за это время найти?

                                                        P.S. Забить не смогу, я обещал проверить свой проект после вычистки cppcheck и clang static anayuzer и написать честный отчет, насколько PVS-studio лучше бесплатных проектов. Рабочая гипотеза примерно совпадает с тем, что вы написали — некая мелочевка нашлась, но времени не окупает.
                                                          +3
                                                          Сколько времени вы потеряли на проверку результатов статанализа и сколько бы стоили те фичи, которые бы вы смогли за это время написать? Ну или сколько реально проявляющих багов могли бы за это время найти?

                                                          Полдня на настройку автоматического сбора статистики по стат-анализу в рамках CI. Полдня на снятие сливок. Самостоятельный поиск тех самых багов с многопоточностью съел бы вряд ли меньше дня… а мог и больше слопать. При этом когда бы они сыграли — фиг его знает… Но последствия, хоть и только репутационные, но были бы весьма неприятны. Остальные бонусы шли оверхедом и в принципе всё выше минора по оценке стат-анализа было оправдано в разборе и правке.

                                                            –5
                                                            У нас с вами — разные предпосылки. Вы верите, что можете исправить все баги, а я знаю, что могу лишь уменьшить их плотность и увеличить MTBF.

                                                            Вы потеряли день на нахождение багов, которые не проявлялись в вашем проекте. Вместо этого вы могли исправить 3-15 багов, которые проявляются и мешают вашим пользователям. Или написать пару позарез нужных фичей.

                                                            Правилен ли такой обмен? Стоит ли менять реально полезную работу на лишь потенциально полезную?

                                                            Другой случай, если бы у вас в этот момент вообще бы не было никакой полезной работы. Вот тогда обмен правильный. Но подобная ситуация (то есть простой) бывает только на саппорте. У девелоперов она редкость.
                                                              +1
                                                              А давайте теперь еще дружно начнем забивать на рост тех. долга, писать говнокод лишь бы работал, забьем на проектирование, документацию, производительность, написание тестов… Ведь вместо этого можно радостно новые фичи добавлять или мешающие пользователям баги фиксить.
                                                              Звучит абсурдно, не правда ли? Исправление косяков найденных стат. анализом это вещь ровно того же порядка. К сожалению в моей сфере деятельности такие инструменты отсутствуют, да что там, даже тесты пишут доли процента и я не в их числе, но сам не раз искал и исправлял ошибки возникшие по причине опечаток и копипаста, при этом времени уходила уйма.

                                                              // Не удержался все таки…
                                                                –1
                                                                Звучит абсолютно нормально. Именно так и делается MVP, а так же макеты и прототипы.

                                                                Про то, что рост технического долга — это не так плохо, есть достаточно много статей на хабре. Например эта или эта.

                                                                Ну да, есть люди, которые из принципа не берут кредиты. Точно так же есть люди, которые не делают технический долг. Но разумная стратегия — это использование и кредитов и технического долга для ускорения развития.

                                                                К сожалению в моей сфере деятельности такие инструменты отсутствуют

                                                                Если вам так хочется написать статанализ на 1С я, наверное, могу поделиться исходниками синтаксического анализатора 1С.

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

                                                                  0
                                                                  Хм, действительно, посыпаю голову пеплом что умудрился такую штуку проморгать, хотя когда впервые про pvs услышал поискал на тему 1с, в то время почему то не нашел. Пока что не имею возможности приобрести, но в течении нескольких месяцев возможно сподоблюсь и отпишусь.

                                                                  Про MVP слышал конечно, и не считаю что тех. долг нужно тут же исправлять как только появится, но ведь до маразма доходит же что функциональность пишется вообще без проектирования, с дикими костылями и говнокодом, и в таком виде и замораживается, ибо трогать страшно — развалится. Впрочем даже если и не трогать — ошибки лезут из всех щелей, приходится на каждом проекте их заново править. В итоге дорабатывать нашу систему под каждого заказчика это такая боль… Особенно если это правки в существующем функционале.
                                                                    –1
                                                                    До маразма может и в обратную сторону доходить. Товарищ не пишет нужную функциональность, потому что в ней при сильной нагрузке может быть ситуация из которой он не придумал, как выбираться.

                                                                    Сильная нагрузка — это в сотню раз больше планируемого максимума.
                                                                    0
                                                                    Это то, что у Джоэла называется «огонь и движение»?
                                                                    (И пятилетней давности новость про патент танка, стреляющего экскрементами.)
                                                          +1
                                                          del
                                              +4

                                              Качественный статический анализатор может найти и ошибки в сложных алгоритмах. Если у вас программа перебирает сложный набор состояний нескольких переменных в цепочке условий, статический анализ легко предупредит вас, например, что вы одно и то же состояние проверяете дважды или что две проверки взаимоисключающие.

                                                –3
                                                Да, разумеется, об этом классе ошибок и бесплатный gcc предупреждает (если писать через switch). Вопрос в том, стоит ли за платить за это немерянные килобаксы.

                                                По личному опыту использование cppcheck не оправдалось. То есть время, потраченное на разбор — не оправдывается тем, что он нашел.

                                                Типичный баг, найденный cppcheck
                                                Угу, если пираты захватят корабль, вскроют наш ящик, спаяют кабель, зайдут с консоли и вместо rm -rf / начнут вводить очень длинные параметры командной строки — будет плохо. Но это не те проблемы. которые есть смысл исправлять. Потому как пиратам проще пристрелить капитана. Ну раз уж они все равно на судне.

                                                А ошибки в алгоритма — это, например, неверное прочтение ИКД (интерфейсно-контрольный документ). Или баг в самом ИКД (такое было в ГЛОНАСС). Или использование не того алгоритма. Или забыли реализовать полезную функциональность.
                                                  0

                                                  Вы экстраполируете опыт использования cppcheck — весьма примитивного анализатора — на коммерческий продукт, который умеет детектить в разы больше ошибок?

                                                    –4
                                                    В общем, надо не стесняться заставлять программистов использовать статический анализ кода. Пусть даже не PVS-Studio, пусть это будет хотя бы Cppcheck (выполняет простые проверки, но зато бесплатен). Это уже будет большим хорошим делом. Программист, конечно, может капризничать, поэтому стоит проявить твердость.


                                                    Как видите, это не я, это команда PVS-Studio.

                                                    Лично я экстраполирую их опыт проверки их собственного кода. Как видите — найденное вряд ли стоит потраченного времени.
                                                      +1

                                                      Очевидно же, что проверка их собственного кода находит минимум реальных проблем, потому что они и так постоянно им пользуются и исправляют дефекты по мере появления. Поэтому авторы и советуют постоянно пользоваться анализатором. Что же касается потраченного времени, то сколько в среднем человеко-часов в вашей команде стоит устранение бага, который мог был быть выловлен анализатором?

                                                        0
                                                        Очевидно, что вы не читали их статью

                                                        Из-за недосмотра C# код плагина для Visual Studio не был добавлен в ежедневные ночные проверки, которые мы проводим. И, соответственно, в отличие от ядра анализатора, ошибки в нем не замечались на протяжении всего развития C# PVS-Studio.


                                                        Увы, я тоже автор статанализатора. Для очень простых языков, но тем не менее. И к сожалению я знаю, что может найти статанализ, а что не может. Устранение бага, который мог быть пойман анализатором, как правило, не стоит потраченного на него времени.

                                                        Возможно, есть исключение для софта, баги в котором являются уязвимостями. Но на софт к такому не относится. Если уж ящик открыли — то проще сжечь процессор пьезозажигалкой, чем искать уязвимости в софте.

                                                    +2

                                                    Через 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.

                                                      –3
                                                      — Я духов вызывать могу из бездны!
                                                      — И я могу, и всякий это может. Вопрос лишь, явятся ль они на зов.


                                                      То есть этот код — только переписывать.

                                                      Начнем с того, что PVS-Studio прежде всего ругнется на int a = getA(); чем-нибудь типа V707. Потом так же на int b = getB();, потом — на if(a <= 0 && b >= 0) — ибо ситуация a=0, b=0 проверена раньше.

                                                      Если… обозначает код того же уровня, то вы получите предупреждений — примерно столько же, сколько строк в коде. И сумеете ли вы найти в этой каше то, что важно лично вам — это большой вопрос.

                                                      Есть лишь один случай, когда нужно писать такую лапшу- когда она описана в ГОСТ или РД. Ну как пример — РД 50-25645.325-89.
                                                      image.
                                                      Вот тут и однобуквенные переменные и куча других странностей. Но хочешь результат, совместимый с другими — значит делаешь по ГОСТ.
                                                        0

                                                        Вы передёргиваете. Разумеется, тут синтетический пример, оттого и переменные однобуквенные. Но в реальном коде анализатор во всём будет прав. И если он выдаёт столько предупреждений, значит действительно с кодом что-то не в порядке. Другой момент, что если if (b == 1) было внесено позже, то анализатор намного быстрее заметит это, чем вычитка автором, код-ревью командой или проверка QA. Или их время не важно и легче действовать тоталитарными методами?

                                                          –1
                                                          Да, заметит быстрее. Но будет ли это дешевле? Личный вертолет — быстрее велосипеда. Вы себе вертолет уже купили?

                                                          Один из авторов PVS-Studio дал нижнюю оценку эффективности в 250КLoc. Вы с этим согласны?
                                                          0
                                                          прежде всего ругнется на int a = getA(); чем-нибудь типа V707

                                                          Кто вам сказал, что это глобальные переменные? Да и суть не в именах.


                                                          потом — на if(a <= 0 && b >= 0) — ибо ситуация a=0, b=0 проверена раньше.

                                                          Почему вы считаете, что на это условие нужно ругаться? Я хочу, чтобы (a, b) = (-1, 0) и (0, 1) заходили в эту ветку. Как вы напишете второе условие?

                                                            0
                                                            Почему вы считаете, что на это условие нужно ругаться? Я хочу, чтобы (a, b) = (-1, 0) и (0, 1) заходили в эту ветку. Как вы напишете второе условие?

                                                            Там первое условия if(a >= 0 && b <= 0) съест этот случай

                                                              0

                                                              Возможно, я плохо выразился или вы плохо подумали. При a = -1, b = 0 мы не зайдём в первую ветку. При a = 0, b = 1 мы тоже не зайдём в первую ветку.

                                                                0

                                                                Скорее всего вы пропустили нюанс: в условие a <= 0 && b >= 0 входит в том числе случай a,b=0, который проверен условием выше, а потому статический анализатор на него должен агриться.
                                                                Но выполнение такого требования будет работать в ущерб читабельности второго условия — его нужно будет расширять, например до (a == 0 && a != b || a < 0) && b >=0.

                                                                  0

                                                                  Почему вы решили, что я пропустил нюанс? Этот нюанс был специально добавлен моими заботливыми руками в код, чтобы показать, что код бывает непростым. Если статический анализатор будет на такие нюансы ругаться, будет очень много ложных сработок.

                                                    0
                                                    Причина простая: основные баги — в алгоритмах. В работе аналитиков. математиков. постановщиков, алгоритмистов. А багов при кодировании — не так много.
                                                    Некоторые мысли про это.
                                                    +1
                                                    > Это в принципе неверно, потому что большинство ошибок — алгоритмические.

                                                    С сотрудниками той квалификации, которую Вы описываете тут и в одном из предыдущих постингов, где мы общались — возможно, так и есть.
                                                    Но это никак не соответствует основной массе программистов. Могу сказать за себя — я периодически делаю такие ошибки, которые выявляются статическими анализаторами. И если бы получить честный опрос всех программистов — таких было бы, думаю, 99%.
                                                    Я крайне рад, что Вы исключение.
                                                      0
                                                      Давайте не путать. я тоже делаю ошибки, которые выявляются компиляторами. Дело не в этом, а в том, каких ошибок больше.

                                                      Если вы пишете 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.

                                                        –1
                                                        Собственно посмотрите на те программы, которыми вы пользуетесь. Как часто вы находите в них баги? А как часто сожалеете, что в них нету нужной вам фичи? А как часто оказывается, что вас не устраивает поведение программы, но это by design?
                                                          0

                                                          Icons8 Lunacy. На C#. И да, она регулярно падает.

                                                            –1
                                                            Падает — это аварийно завершает выполнение без сохранения? Тогда это design-bug.

                                                            В Windows — структурные исключения. Любую программу можно написать так, чтобы при аппаратных exception, она не завершала работу, а выдавала сообщение и давала возможность продолжить работу. Если бояться за порчу данных — их можно защитить проверкой CRC или MD5. Так сделано в VCL (delphi, с builder и так далее).

                                                            То, что word падает без сохранения — это ровно такой же design-bug.

                                                            Увы, design-баги не находятся статанализом.

                                                              0

                                                              Это просмотрщик. Сохранять ему ничего не нужно. Разумеется, программист должен был корректно обработать исключение, но предположим, что ошибка произошла в коде на C++ из-за некорректного обращения к нулевому указателю. Что лучше будет для пользователя: обработать исключение, показав пользователю "Извините, произошла ошибка", или найти и устранить её? Тем более, что статический анализ позволяет находить некоторые виды обращения к нулевому указателю.

                                                                0
                                                                Обработка исключений. Она сводит критические ошибки к обходимым, При этом действует сразу на все ошибки.

                                                                А устранить все исключения на бытовом компе не реально. Всегда возможен сбой памяти из-за космических лучей. Там, где надо, чтобы исключений не было — там используются два двухголовых компа. Каждый двухголовый — повторяет все операции на обоих процессорах и своей памяти. Если процессоры разошлись хоть на бит — управление передается второй паре двухголовых.
                                                                  0

                                                                  Так чем эта обработка исключений поможет пользователю в данном конкретном случае?

                                                                    –1
                                                                    сводит критические ошибки к обходимым

                                                                    P.S. Если не понятно, подумайте, что было бы, если бы браузер падал при ошибке в загрузке web-страницы.
                                                                  0
                                                                  Те, кто не обрабатывает исключения — похожи на людей, которые считают, что дом имеет право развалиться из-за трещины в одном кирпиче.

                                                                  Подходишь к дому 18века. Некоторые кирпичи — крошатся в руках. А дом стоит. Ибо строители никогда не надеятся, что все кирпичи будут без багов
                                                      +2

                                                      Ваш компилятор детектит опечатки вроде V501?

                                                        –6
                                                        Не было таких ошибок в коде, так что не проверял.
                                                          +3

                                                          А откуда вы знаете, что в ваших проектах нет таких ошибок?

                                                            –7
                                                            [SARCASM ON]
                                                            А откуда вы знаете, что вы не шпион гондураса? Может быть вас во сне завербовали? А давайте вы купите нашу программу за полмиллиона, мы тогда вас проверим и скажем, шпион вы или нет. Да, мы умеем проверять не только на Гондурас. Ещё Гватемала и 50 других стран. Из европейский, правда, только Монако, Люксембург и Андорра, но этого тоже не мало,
                                                            [SARCASM OFF]

                                                            Неужели вы думаете, что я не знаю наизусть код своего проекта? Проекты до 100 тысяч строк помнятся целиком.

                                                            А в помните каждый час своей жизни, чтобы утверждать, что вас не завербовали в шпионы?
                                                              +4

                                                              Я думаю, что у вас завышенное ЧСВ. Впрочем, статья как раз об этом, и о том что таким заявлениям программистов верить нельзя. Вы можете быть уверены, что закодировали всё правильно, но досадные опечатки могут быть у каждого. Анализатор сразу об этом скажет, и ни QA, ни менеджер, ни заказчик об этом даже не узнают, так что самооценка не пострадает.

                                                                –6
                                                                Думаю, что вы все-таки шпион Гондураса. Просто платить не хотите. :-)

                                                                ЧСВ у меня скорее заниженное, компилятор мне об ошибках рапортует ежедневно. Не в этом дело. А в том, что ошибки, найденные станализатором — не стоят времени, потраченного на анализ. Вот вам пример от PVS-Studio.

                                                                Скажите, сколько своих денег вы готовы заплатить за продукт, который находит такое количество ошибок? Мне вот жалко времени, потраченного на анализ выдачи.
                                                            +5
                                                            О, Евгений предсказал это.

                                                            Для тех, кто не понял юмор. V501 есть у всех (FreeBSD, Clang, Far, Blender, GCC, Unreal Engine, Chromium, Qt, TortoiseSVN, ...)
                                                              –4
                                                              Это типичная ошибка мышления. Вы перечисляете верблюдов, созданных комитетом. И уверены, что у всех животных — есть один-два горба. Но не понимаете, что у кенгуру — все иначе. Два члена, переменный срок беременности, если голодает — беременность рассасывается, есть сумка, горбов почему-то нет и так далее…

                                                              Вы бы хоть глянули, есть ли эта ошибка в той версии FAR, которую писал Евгений Рошаль лично.
                                                            0
                                                            Ок, предположим что не детектит (я не в курсе что это за ошибка). Попробуем посчитать ценность детекта.

                                                            Возьмем команду в 6 человек, лид, аналитик, 2 дева, 2 QA. 100 евро в час каждый. Цикл разработки: аналитик сидит на клиенте, девы пилят по аналитике, QA тестируют (перед продом и на проде), лид вмешивается при багах.

                                                            На проде возникает ошибка из-за V501.
                                                            Лид тратит час на косяк (откат\разбор\новый релиз), дев час на анализ\фикс, QA два часа на тесты (один раз когда заметил баг, другой раза когда тестировал фикс).
                                                            Итого — потеря в 400 евро. Сценарий пессимистичный.

                                                            Оптимистичный сценарий: разраб + QA найдут этот косяк уже на тестовом стенде и пофиксят его в обычном режиме. Потери — 0.

                                                            Вероятность пессимистичного сценария — 5%. Оптимистичного — 95%. Мат. ожидание потерь от V501 — 20 евро. А теперь вопрос: сколько V501 случаются в рядовом проекте?

                                                            Цифры выше взяты с потолка.

                                                            Я видел много статей от PVS-Studio. Видел очень даже неплохие статьи для разработчиков (типа «топ самых популярных ошибок»), но пока еще не видел хорошей статьи с подсчетом выгоды от детектов. Ребята, у вас куча чекнутых проектов. Соберите статистику по частотам ошибок («V123 встречается 0.55 раз в 1000 строк кода»), и у вас появятся хоть какие-то цифры для разговора с менеджерами.
                                                              +3
                                                              Всё просто. Если ошибка стоит 20$, то этому проекту не нужен статический анализатор. Впрочем, это какой-то волшебный проект. В настоящем проекте цена ошибки на порядке выше.

                                                              В любом случае, если картина такая, как Вы описали, действительно продать анализатор невозможно. Однако есть другой класс проектов, где ошибка или простой программы выливается в большие деньги. Я, например, знаю случай, когда анализатор PVS-Studio нашел ошибку возрастом в 2 года (там было что-то в духе x*(10/3) из-за которой клиентам автоматически выставлялась неправильная заниженная цена не некоторую группу товаров. Причем, программист рассказал мне по секрету, что побоялись даже доложить начальству об этой ошибке и просто решили втихомолку её исправить.

                                                              Еще я знаю случай, когда команду разработчиков несколько раз катали на самолёте на другую сторону земного шара, чтобы они сидели и ждали, когда система опять упадёт, чтобы на месте найти наконец и исправить злосчастный баг, который проявляет себя, как только программисты улетают домой. Оказался неинициализированный член класса.

                                                              Я к тому, что ошибки бывают очень дорогие, но при этом до безобразия простые и могли быть легко выявлены анализатором кода. И кстати, менеджеров таких проектов, в отличии от программистов, как-то даже не надо убеждать, что ошибки, это плохо и надо постараться сразу найти их как можно больше.
                                                                –2
                                                                Вот в двух описанных вами ситуациях — согласен, статнализ полезен. Вот только цифры бы — насколько часто встречаются именно такие ошибки? Точнее насколько часто по сравнению с другими… Пока что сколько вы не искали в открытых проектах — таких багов вы не нашли.

                                                                Что касается второго случая — то это баг архитектуры. Правильно сделанная система АСУТП поднимается после любого бага. То есть она изначально рассчитана на падения.
                                                                  –6
                                                                  Кстати, на подобных проектах наверное и компы освящают и ещё много чего делают. Стоит недорого, а вдруг поможет?

                                                                  Примерно так же 100 лет назад в деревнях сначала шли с подарками к батюшке, а потом к колдуну. Не то, чтобы верили, но вдруг кто-то из них и вправду поможет?
                                                                    +1
                                                                    Кстати, gcc репортит неинициализированные члены класса. Так что этим людям статанализатор не помог бы.
                                                                      +1
                                                                      Помог, не помог… С удовольствием пользуются несколько лет PVS-Studio. Огромный проект на Visual C++ и никакой речи даже нет о возможностях там попробовать GCC или что-то ещё.
                                                                        –2
                                                                        И сколько вы нашли важных багов, которые иным путем искали бы очень долго? Ну так, примерно, какая от него реальная польза?
                                                                      0
                                                                      так всё же, у вас не бывает ложноположительных детектов?
                                                                        0
                                                                        Конечно бывают.
                                                                      +3
                                                                      С учетом вашей кармы я даже знаю, чем указанием на ваши ошибки закончатся.
                                                                      Однако неадекватность требует ответа на нее
                                                                      На проде возникает ошибка из-за V501.

                                                                      То есть статическим анализатором в команде пользоваться не умеют, окей.
                                                                      ошибки компилятора вы тоже только на проде замечаете?
                                                                      Сценарий пессимистичный

                                                                      Вы хотели сказать, что сценарий — упоротый?
                                                                      Лид тратит час на косяк (откат\разбор\новый релиз)

                                                                      Ну да, дурная голова ногам покоя не дает.
                                                                      QA два часа на тесты (один раз когда заметил баг, другой раза когда тестировал фикс).

                                                                      Возвращаемся к исходному, что в статический анализ вы вообще никак.
                                                                      QA у вас ищут ошибки с помощью компиляции проекта? И проверяют ошибки, которые выдает компилятор? Серьезно? Если нет, то как они увидят ошибки стат.анализа?
                                                                      Итого — потеря в 400 евро

                                                                      Итого, из-за того, что вы не понимаете, как пользоваться инструментом — в вашем воображении возникают такие вот фантастические сценарии с воображаемыми же потерями.

                                                                      А теперь примерно как должно быть в реальности:
                                                                      2 дева сразу после написания новых куском кода проверяют его стат.анализом. Исправляют ошибки компилятора и стат.анализатора, если они есть, после чего отправляют написанное на тест QA. Лид вмешивается не на предупреждения стат.анализа, а на реальных багах. То есть именно то, что вы описали в «пессимистичном сценарии», только у разрабов появляется дополнительный инструмент проверки только что написанного кода до того, как все это уйдет в QA вообще, а не приходится искать всякие опечатки и неверные куски кода по описанию, что в новом модуле все падает если сделать то-то и то-то.
                                                                        +1
                                                                        С учетом вашей кармы я даже знаю, чем указанием на ваши ошибки закончатся.

                                                                        Вообще говоря, некто Am0ralist мною плюсанут.

                                                                        То есть статическим анализатором в команде пользоваться не умеют, окей.

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

                                                                        Соответственно, оба сценария из предыдущего комментария рассматриваются в контексте отсутствия стат-ана.

                                                                        Вывод прост: при использовании статического анализатора удастся сэкономить условные 20 евро на каждой V501. Цифра условная, взята с потолка.
                                                                        Затраты на обучение персонала — 1100 евро (по часу девам и лиду на ознакомление + 8 часов дева на внедрение в CI и первичную очистку проекта). Цифра условная, взята с потолка.
                                                                        Итог: ради одной только V501 закупать PVS-Studio невыгодно, штука евро минуса.

                                                                        Andrey2008 в комментарии выше приводит примеры в духе «Я, например, знаю случай,». С таким бесполезно подходить к менеджеру. Состоится диалог вроде
                                                                        – От судьбы не застрахуешься, – упорствовал Епишко. – Я вот знаю случай: в грозу человека в чистом поле убило.
                                                                        – А не лезь в грозу в чисто поле! – обозлился Звягин. – А влез – так держись по низинкам.

                                                                        Если проект связан с космосом\медициной\серьезными_деньгами\серьезными_исследованиями — там слова «надежность» может и хватить. Если на проект выделены миллионы — просто впишут анализатор как необходимый софт по слову лида. В рядовом проекте задумаются о цене, времени затраченном на внедрение, и поинтересуются выгодой. И менеджеру выгоду проще всего показать в сэкономленных человеко-часах.
                                                                    +3
                                                                    Вот только бубен стоит 200-300 рублей, а PVS-Studio — немерянные килобаксы. Стоит ли их тратить на технологию с «недоказанной эффективностью» — непонятно.

                                                                    Не отпугивайте народ :). Наши цены очень даже скромные по сравнению с Coverity, Klocwork. Мы сознательно выбрали среднюю ценовую нишу и живём в ней. Мы тем, кому PC-Lint уже кажется устаревшим/простоватым/неудобным/не умеющий C++14 (а новый они вот уже 3 года делают на основе Clang, но пока всё никак), а цены на Coverity/Xyz уже перебор.

                                                                    Причем, в плане диагностик мы уже наступаем на пятки Coverity/Klocwork. Так что соотношение результат/цена весьма привлекательно. Покупайте наших слонов!
                                                                      –5
                                                                      Вы случайно самолеты не продавали? А то ну очень аргументация похожа. Ну или антивирусы?

                                                                      Мне не важно, насколько вы дешевле Coverity. Мне важно, насколько вы лучше бубна и всех остальных плацебо. Причем не просто «мы нашли багов в десять раз больше, чем пляски с бубном». А разница в количестве багов на рубль затрат. Бубен-то я и за 200 рублей купить смогу.

                                                                      А эффективность доказывается двойным слепым рандомизованным исследованием. Которого у вас нет.

                                                                      P.S. У меня и резидентный антивирус не стоит (но стоял firewall). И за последние лет 10-15 я отослал в Dr.Web и Касперского немало зверушек. Сказки про то, что без резидентного антивируса сразу комп обрастет вирусами — верны для домохозяйки. Но не верны лично для меня.

                                                                      Вот и вам совет — узнайте своего пользователя и опишите его. Может и действительно есть такие области, где статанализ выгоднее бубна.
                                                                  +2

                                                                  Если честно, то не сталкивался с людьми, возражающими против инструментов статического анализа, проверки/исправления стиля и в принципе строгой проверки ошибок и предупреждений.


                                                                  Это наверно какой-то пещерный вид для зоопарка и гнать их нужно в шею, т.к. за такой вершиной айсберга скрывается ещё больший пласт проблем: ручные сборки в особо настроенной среде, "секретные знания", собственничество с припадками, удручающее качество кода и отсутствие целостной архитектуры в принципе.

                                                                    +3
                                                                    Сталкивался с людьми которые против конкретно PVS-Studio. Аргумент — «задолбали». Он вне бизнес-плоскости, однако лично мне понятен.
                                                                    –8
                                                                    А с людьми возражающими против окропления святой водой, вы сталкивались?

                                                                    «За такой вершиной айсберга» у меня работа системы 365 на 24 в течение 15 лет.

                                                                    И не путайте божий дар с яичницей. Процентов 50 предупреждений компилятора — это реальные баги, которые надо править. Была бы у статических анализаторов эффективность хотя бы 5% — цены бы им не было.

                                                                    Кстати, авторы PVS-Studio считают, что в любом проекте при -Wall -Wextra вылезает сотня предупреждений. Если надо — найду вам цитату. У нас почему-то наоборот — ни предупреждений, ни хинтов.
                                                                      +3
                                                                      «За такой вершиной айсберга» у меня работа системы 365 на 24 в течение 15 лет.
                                                                      Не берусь конечно утверждать и не хочу никого обидеть, однако выскажу своё мнение. Когда заходит речь о системах, которые работают 10 лет подряд, то потом выясняется, что речь идёт о весьма и весьма простых программах, которые действительно можно написать без ошибок. Ведь закон экспоненциального роста глючности никто не отменял. А в системах, работающих годами слабый процессор, мало памяти и как следствие маленькие программы. В них часто часто память выделяется только один раз при запуске. Нет выделений памяти и уже нет массы проблем и ошибок.

                                                                      Процентов 50 предупреждений компилятора — это реальные баги, которые надо править. Была бы у статических анализаторов эффективность хотя бы 5% — цены бы им не было.
                                                                      Процент сообщений анализатора PVS-Studio, с которыми стоит что-то сделать:

                                                                        –5
                                                                        Согласен. Любая надежная система, является простой. Даже если в ней 10 миллионов строк кода и тысяча человек. И наоборот, любая глючная система — сложна, даже если в ней всего пара тысяч строк кода. Вам не кажется, что это аксиома? Более того, мастерство программиста в том и состоит, чтобы сделать максимально простой код.

                                                                        Глюки, баги (ошибки) и надежность системы — это разные вещи. Глюки — это почти не воспроизводимые ошибки, например — состояние гонки. Статический анализ не помогает их искать. А баги…

                                                                        Представьте себе, что у вас дом рушится из-за трещины в одном кирпиче. Как нравится? Хочется жить в таком доме? Вот так и мне не нравится пользоваться программами, автор которых решил, что самое главное — устранить все баги. Потому что основное — это обеспечить работу программы независимо от наличия в ней багов.

                                                                        А в системах, работающих годами слабый процессор, мало памяти и как следствие маленькие программы

                                                                        Ну как пример — OS/360. Там порядка миллиона строк кода и тысяча человеко-лет. При этом она вполне выполнялась на машинах с 200 тысяч операций в секунду и 256 килобайт памяти. Вы считаете, что это небольшая программа? Там только компиляторов пяток был.

                                                                        Процент сообщений анализатора PVS-Studio, с которыми стоит что-то сделать:
                                                                        Far — 50%

                                                                        Что-то надо сделать с любым сообщением. То есть потратить время, проанализировать код и принять какое-то решение. Реальные показатели этого проекта «плотность будет равна 0.464 ошибки на 1000 строк кода». Это означает, что в FAR остались баги типа «если залезть на шкаф и высунуть в окно телескоп то в коне дома за 3 километра мы увидим голую задницу», А если на шкаф не залезать — не увидим.

                                                                        И это означает, что правильное решение менеджмента — направить силы не на исправление багов, а на то, что нужно пользователям. То есть на развитие проекта. Или на исправление реальных (проявляющихся у пользователей) багов. Потому что основные баги — они не в кодировании, а в алгоритмах.

                                                                        Если вам интересны параметры нашей системы, то там 135 тысяч строк и 10 человеко-лет. В серверной част работает два десятка нитей. Теоретическая плотность ошибок — 2-4 ошибки на тысячу строк. Время на комплексную отладку — ноль. Теоретически у нас было два часа в месяц, но мы их не использовали. Количество багрепортов за время промышленной эксплуатации (15 лет) — ноль. Что не означает, что багов там нету. Просто система сделана так, что она надежна несмотря на баги.
                                                                          +3
                                                                          Если вам интересны параметры нашей системы, то там 135 тысяч строк и 10 человеко-лет.
                                                                          Теперь всё понятно. У вас очень маленький проект. И да, в таком проекте использование статического анализатора не является по настоящему нужным: низкая плотность ошибок, возможность обозреть весь проект и осознавать, как он работает.

                                                                          Числа для сравнения. Весь проекте PVS-Studio мы считаем небольшим. А ядро C++ анализатора PVS-Studio вообще маленьким. Так вот, маленькое C++ ядро PVS-Studio содержит 225884 строк кода.

                                                                          Это, пожалуй, пограничный размер, когда ещё можно обходиться без статического анализа кода. Мы используем инструменты для анализа своего кода (было бы странно для нас не использовать :). Но повторюсь, процесс развития проекта и его качество ещё можно контролировать вручную. Если же речь о 135000, то тут конечно сложно продемонстрировать полезность инструментов статического анализа.
                                                                            +1
                                                                            Ну так об этом и надо было писать в статье! То есть о том, что речь идет о проекта больше 250KLoc.

                                                                            И все-таки, проверьте гипотезу, что дело не в строках кода, а в количестве девелоперов. FAR 1.65 производства Рошаля не сильно отличается по возможностям от FAR 3.0 (сделанного сообществом). Интересно, насколько он отличается по плотности ошибок.

                                                                            Если же речь о 135000, то тут конечно сложно продемонстрировать полезность инструментов статического анализа.

                                                                            Зато инструменты динамического анализа полезны при любом размере. Например, у меня там был собственный анализатор утечек памяти. Заодно — они более-менее кроссплатформенны. Тот проект все равно PVS-Studio не проверит, он на Delphi (Object Pascal) был написал.

                                                                            Нынешний, проверку которого я вам обещал — на С с элементами С++. Но он меньше 50KLoc,

                                                                            Ну я рад, что мы сошлись. И даже поставил плюс в карму.
                                                                            0
                                                                            > Ну как пример — OS/360. Там порядка миллиона строк кода и тысяча человеко-лет. При этом она вполне выполнялась на машинах с 200 тысяч операций в секунду и 256 килобайт памяти. Вы считаете, что это небольшая программа?

                                                                            Для своего времени (1964) это была очень большая машина. На небольших (с памятью типа 64K) OS/360 могла вообще не идти (были всякие DOS/360 и тому подобные).

                                                                            > Там только компиляторов пяток был.

                                                                            Угу. Только вот, например, Fortran G не оптимизировал, а Fortran OE имел столько багов, что непонятно было, как его результат можно вообще использовать. Баги они были и в этой системе.

                                                                            > Реальные показатели этого проекта «плотность будет равна 0.464 ошибки на 1000 строк кода». Это означает, что в FAR остались баги типа «если залезть на шкаф и высунуть в окно телескоп то в коне дома за 3 километра мы увидим голую задницу», А если на шкаф не залезать — не увидим.

                                                                            Один баг может создать критическую неработу, а 10000 — не влиять ни на что. При чём тут эти сравнения со шкафом?

                                                                            > Если вам интересны параметры нашей системы, то там 135 тысяч строк и 10 человеко-лет.

                                                                            Тут рядом сказали уже, но поддержу — это очень небольшая система, тем более на такое время работы. Даже если считать, что этот объём за половину того времени — то за это время можно было буквально вылизать код.
                                                                              0
                                                                              Для своего времени (1964) это была очень большая машина.

                                                                              А OS/360 и до сих пор — большая система. Хотя характеристики STM32F7 — получше, чем у первых IBM/360. Так что сейчас и на STM32 можно большие системы делать.

                                                                              Один баг может создать критическую неработу, а 10000 — не влиять ни на что. При чём тут эти сравнения со шкафом?

                                                                              Вы используете FAR? Если да, то попробуйте найти в нем баги. Традиционный способ ловли ошибок прежде всего вычищает наиболее часто встречающиеся ошибки. А вот статанализ дает почти равный вес и тому, что сработает у 80% пользователей, и тому, что у 0.001%, да ещё и в экзотических условиях использования. Последнее и называется «а вы на шкаф залезьте».

                                                                              Тут рядом сказали уже, но поддержу — это очень небольшая система, тем более на такое время работы.

                                                                              Классическая производительность программиста — 10 строк отлаженного процедурного кода в день. Это не означает, что за день нельзя написать 1000 сырого строк. Можно. Только потом ещё 3 месяца (в общей сложности) уйдут на отладку. Так что времени мы потратили в 4 раза меньше, чем нужно по классике.

                                                                              Вы, наверное, смотрите нормы для объектного кода. Ну да, вместо процедуры на 10 строк на C++ можно написать объект на 100 строк, где 90 будут стандартной обвязкой. Тогда нормы увеличиваются. Мы писали на Delphi. там уместен коэффициент 2-3 относительно классического фортрана.

                                                                              Что касается вылизывания… Мы с самого начала решили что мы не боги. И ошибки у нас будут. В том числе — и неизвестные нам ошибки. Поэтому вместо вылизывания кода мы сделали так, чтобы система работала независимо от наличия багов. Как «ванька-встанька», которого не положить. Это довольно дорого, по оценке 30% времени ушло именно на поддержку «ваньки-встаньки»…
                                                                        +5
                                                                        Если честно, то не сталкивался с людьми, возражающими против инструментов статического анализа,
                                                                        Вот сейчас Вы с ними и познакомитесь. :)
                                                                          –2
                                                                          Просьба не передергивать, я не против статического анализа вообще. Тот статанализ, что встроен в gcc и clang — более, чем полезен. А вот цена PVS-studio — не оправдывается той мелочью, что он находит. По крайне мере, если судить об этом по блогу самой PVS-studio. Ну а cppcheck — просто не стоит времени, потраченного на разбор того, что он выдал.

                                                                          И еще раз повторюсь. Причина ложных срабатывай — отнюдь не баги в коде. Это проблемы алгоритмов. У других проектов — ситуация примерно такая же. Поэтому, если есть лишние деньги — разумней их тратить на развитие.

                                                                          Признайтесь честно, вы же не купили себе coverity? Хотя некоторое количество багов он бы вам нашел. Вот и другие не хотят покупать примерно по тем же причинам.
                                                                          +2
                                                                          Мне показалось, что говоря «против инструментов статанализа» автор имеет в виду «против ПВС-студии». Это сильно разные вещи таки.
                                                                          +3
                                                                          Прогнал свой личный проект, из 13к более-менее осмысленного кода, реальных ошибок было 3 штуки, ложных срабатываний — около 15 штук. Использовал бесплатную версию. Программистом себя считаю ниже среднего уровня. Тулза особенно полезна на огромных проектах, как я вижу из статей.
                                                                            +1

                                                                            Тут ещё штука, смотря что считать ложным срабатыванием. Некоторые называют ложным срабатыванием любой код, который не приводит к реальному багу. К примеру, повторное условие в цепочке OR, которое уже было в той же цепочке. Однако это не ложное срабатывание. Такой код — мина замедленного действия. Завтра надо будет расширять это условие и новый разработчик будет не уверен, действительно ли ветка лишняя и её надо убрать или имелось в виду что-то другое, и её надо оставить. Он потратит время, чтобы разобраться, и может прийти к неверным выводам, внеся новый баг.

                                                                              +2
                                                                              В подтверждение ваших слов приведу пример из моего недавнего общения с разработчиком открытого проекта:

                                                                              Код с ошибкой (бессмысленный код, мина… трактуйте как хотите):

                                                                              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.

                                                                              Ну нет, так нет. Путь будет ложным срабатыванием жить вечно в коде.
                                                                                –1
                                                                                Думаю, что дело в поиске. Если автор кода часто использует поиск — ему удобнее писать именно так, чем bool shouldIncludeSizedInit = shouldIncludeStructInit;

                                                                                По этим же причинам используются две переменные вместо одной. gcc все равно оптимизирует общие выражения и сделает замену переменных. А вот при поиске по shouldIncludeSizedInit покажутся куски кода, связанные именно с этой функциональностью.
                                                                                  –1
                                                                                  Тьфу, я неправ, там != во второй строке.
                                                                                  Так что вообще не вижу причин удивляться такому коду. Логика простая. Птицы — это не звери. Но и те и те теплокровные.
                                                                                    +1
                                                                                    Тьфу, я неправ

                                                                                    Вот, вот оно! Вы видите! Вы сами можете проморгать в коде существенное отличие в двух строчках! Глаз замыливается. Как же вы можете гарантировать, что никогда не проморгаете такое отличие в своём коде?
                                                                                    Тут как раз статанализ и приходит на помощь. Если б две подряд идущих переменных были бы инициализированы точно одинаковыми условиями, он бы ругнулся на это, а иначе ругается на другое. А варнинги gcc здесь не помогают.

                                                                                      0
                                                                                      Отличный пост, будем на него ссылаться теперь, особенно при общении с Jef239. :D
                                                                                        –2
                                                                                        Свой код я все-таки пишу, а не только читаю. Опечаток у меня много, но вот такого типа — не припомню. Зато «точка хрения» бывает регулярно.

                                                                                        Методик, которые помогают — много. Вопрос в том, какие из них оправдывают свою цену. В конце концов предупреждения компилятора — это тоже статический анализ. Просто разработчики gcc выбрали набор предупреждений с низким числом ложных срабатываний.
                                                                                  +4
                                                                                  Тулза особенно полезна на огромных проектах, как я вижу из статей.

                                                                                  Да, анализатор становится всё полезнее с ростом проекта. Чем больше проект, тем больше плотность ошибок. 13k — это очень маленький проект.

                                                                                  image
                                                                                  Таблица. Книга Стива Макконнелла «Совершенный код». Размер проекта и типичная плотность ошибок. В книге указаны источники данных: «Program Quality and Programmer Productivity» (Jones, 1977), «Estimating Software Costs» (Jones, 1998).

                                                                                  Таким образом, есть шанс, что в таком проекте вообще не будет ошибок. :)
                                                                                  +3
                                                                                  За что в свое время выбрали зенд студию как пхп-иде — так это за встроенный (хотя и простой) статический анализатор кода. Штука полезная. Но до определенной степени, когда ложных срабатываний накапливается слишком много — разумнее игнорить, чем обращать внимание.

                                                                                  В группе из 100 человек 50 всегда будут выше и 50 — ниже среднего
                                                                                  Вот точно, статья для менеджеров. Программист или математик сразу увидит неточность (или даже ложность) этого утверждения.
                                                                                  Объяснение для менеджеров: если уборщица получает 5 рублей, ее менеджер получает 25рублей, управляющий ее менеджера получает 30р и программист получает 30р, то среднее (арифметическое) будет 22.5, при этом 75% персонала будет получать зарплату выше средней. А отнюдь не 50%.
                                                                                    +2
                                                                                    Но до определенной степени, когда ложных срабатываний накапливается слишком много — разумнее игнорить, чем обращать внимание.
                                                                                    Статический анализатор используется неправильно. Они не должны накапливаться! Полная аналогия с предупреждениями компилятора — их не должно быть. Иначе вступает в силу теория разбитых окон.
                                                                                      0
                                                                                      Анализатор используется правильно. То что они не должны накапливаться — никто не спорит, но это проблема анализатора и его ложных срабатываний. Наличие которых в анализаторе даже авторы pvs не отрицают.
                                                                                        +3
                                                                                        Но ведь и нет никакой проблему убирать новые ложные срабатывания. По крайней мере, если говорить о PVS-Studio.

                                                                                        Для этого есть масса способов. Например, можно изменить код. При этом как правило он становится проще и понятней, причем не только анализатору, но и коллегам. Очень часто анализатор выдаёт предупреждения на код, который написан в стиле «смотрите, как я могу».

                                                                                        Можно подавлять точечно, используя комментарии. Можно использовать базу разметки. Можно исключить файлы из анализа, если там сгенерированный код или какие-то тесты, аномальные с точки зрения анализатора: if (A == A) для проверки реализации оператора ==.
                                                                                          +2
                                                                                          Но ведь и нет никакой проблему убирать новые ложные срабатывания. По крайней мере, если говорить о PVS-Studio.
                                                                                          Э.
                                                                                          Во-первых, мы говорили о зенд-студию когда говорили что их накапливается слишком много.
                                                                                          Во-вторых, мы говорили о пхп и об отсутствии проблем с ложными срабатываниями в pvs студию в пхп можно будет говорить не раньше чем pvs студию научится с пхп работать. Кстати, непонятно почему не работает — рынок достаточно большой, задача сравнительно (с уже реализованными) простая.
                                                                                          И если все же выйти из контекста — выше тоже достаточно жалоб на ложные срабатывания именно в pvs студии.

                                                                                          нет никакой проблему убирать: можно изменить код, Можно подавлять точечно, используя комментарии. Можно использовать базу разметки. Можно исключить файлы из анализа
                                                                                          Навеяло: «нет никакой проблемы забивать гвозди микроскопом — можно изменить гвозди, можно усилить микроскоп в местах сочленения, можно разметить направление ударов что бы микроскоп не ломался, можно некоторые гвозди не забивать».
                                                                                          Понимаете какая штука, инструмент должен экономить время и работать. А когда разработчик инструмента говорит что «инструмент кривоват конечно, но можно же и самому доработать», то это навязывание обязанностей по принципу «ну тебе че сложно что-ли» совсем не радует. До определённой степени дорабатывать можно, но рано или поздно количество доработок и время на них потраченное начинает превышать выгоду от использования инструмента. Это все же не опен-сорц где получаешь удовольствие от доработки и контрибьюта получив его бесплатно, а платный продукт который должен работать на покупателя, а не наоборот.

                                                                                          Возьмем чуть пример в сторону. Вот есть куча коде-бьютифайеров. Каждый разраб свой нахваливает и говорит что мол «даже если что не так можно настроить», а вот в зенд-студии (вторая причина почему она нам нравится) «коде бьютифайер» работает из коробки без косяков. И? И всё.
                                                                                            +1
                                                                                            Понимаете какая штука, инструмент должен экономить время и работать. А когда разработчик инструмента говорит что «инструмент кривоват конечно, но можно же и самому доработать», то это навязывание обязанностей по принципу «ну тебе че сложно что-ли» совсем не радует

                                                                                            То есть код сомнительный пишет разработчик, а кривоват инструмент, который это видит?
                                                                                            Вообще-то ситуация ровно обратная: инструмент показывает, что у вас тут немного кривовато, а разработчик ему может сказать: «забей и так сойдет» и этим экономит время.
                                                                                            А так то и компиляторы можно обвинять в то, что они выводят предупреждение на то, что переменная инициализирована была, но ни разу не использовалась. Я так захотел, чего он мне постоянно это напоминает? Или что переменная используется без инициализации, хотя я точно знаю, что в эту ветку кода никогда исполнение не попадет, не пройдя изначально другую ветку, где переменная инициализируется, просто мне влом переписывать.
                                                                                            Говорит ли это о том, что инструмент плохой, что он не догадался самостоятельно о том, что все ровно так, как я и хотел?
                                                                                              +1
                                                                                              То есть код сомнительный пишет разработчик, а кривоват инструмент, который это видит?
                                                                                              От оно чё, михалычь.
                                                                                              Т.е. «ложных срабатываний» не бывает, бывает только «код сомнительный».
                                                                                              При чем «сомнительный» по мнению стороннего инструмента (для этого кода и проекта), но инструмент разумеется умнее разработчика, ему лучше знать, сомнительный код или нет.
                                                                                                +1
                                                                                                Я про php и зенд-студию ничего не знаю. Но у меня крутится в голове: быть может у вас просто нормального анализатора не было? :)

                                                                                                Например, мы недавно проверяли проект PascalABC.NET с помощью SonarC# и PVS-Studio. И по нашему мнению, дело обстоит так:
                                                                                                image
                                                                                                Не будем точно считать проценты ложных срабатываний, так как мнение может быть предвзятым. Но все равно понятно, что осилить 700 сообщений проще, чем 1800. И ясно, что 1800 может сильно утомить и испортить аппетит к статическим анализаторам.
                                                                                                  0
                                                                                                  Я про php и зенд-студию ничего не знаю. Но у меня крутится в голове: быть может у вас просто нормального анализатора не было? :)
                                                                                                  Может, спорить не будем. Подскажете нормальный?:)
                                                                                                    +1
                                                                                                    Конечно же PhpStorm!* Не знаю насчёт зенд-студии, но в PhpStorm в пару кликов можно подавить, настроить или отключить диагностику, которая вам не по душе.

                                                                                                    * Дисклеймер: я аффилирован с компанием-производителем, и моё мнение может быть небеспристрастным.
                                                                                                      0
                                                                                                      Попробуем, спасибо.
                                                                                                      Хотя 90 баксов за год платить как-то дороговато:\
                                                                                              +1

                                                                                              А в Зенд-студии нельзя подавить ложные срабатывания анализатора или гибко его настроить? К слову, есть мнение, что контроль качества кода должен производиться независимо от используемой IDE. У нас это делается проверкой при коммите (невалидный код просто не будет закоммичен). В C++ можно использовать проверку ветки на CI-сервере.


                                                                                              Кроме того


                                                                                              Штука полезная. Но до определенной степени, когда ложных срабатываний накапливается слишком много — разумнее игнорить, чем обращать внимание.
                                                                                              рано или поздно количество доработок и время на них потраченное начинает превышать выгоду от использования инструмента
                                                                                              платный продукт который должен работать на покупателя, а не наоборот.

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

                                                                                                0
                                                                                                А в Зенд-студии нельзя подавить ложные срабатывания анализатора или гибко его настроить?
                                                                                                Можно, но о том и речь, что на определенной стадии количество настроек и подавлений становится выше некоей критической точки.
                                                                                                И если для проекта разрабатываемого «с нуля», это еще куда ни шло (у нас пет проект у зендовского анализатора вопросов не вызывает), то когда входишь в новый проект и надо неделю потратить на настройку — это уже малоинтересно.

                                                                                                При чем очень много логичных, но необычных придирок. Например, перманентно ругается на if(a=5), ему видишь ли надо что бы if(5=a) было, что бы замечания не выдал. Да, мы понимаем причины, но во многих проектах так пишут?

                                                                                                Ну и какой тогда прок от него?
                                                                                                Ну определенная польза есть. Просто обидно что для использования на 100% нужно прилагать несоразмерное количество усилий по тюнингу.
                                                                                                  0

                                                                                                  Зенд-студия не умеет


                                                                                                  Можно подавлять точечно, используя комментарии.

                                                                                                  ?


                                                                                                  Ну попробуйте php storm… Конкретно с этой IDE не работал, но по идее должно работать так же как и в главной IDE линейки — Idea.

                                                                                                    +1
                                                                                                    Просто обидно что для использования на 100% нужно прилагать несоразмерное количество усилий по тюнингу.

                                                                                                    Не знаю, как там в Зенде настраивается, но в ESLint при подобной ошибке, если такие предупреждения нам действительно неинтересны, то достаточно добавить одну строку в конфиг, чтобы выключить ошибку сразу во всём проекте. И такие микрооптимизации линтинга проще делать по мере поступления проблем.

                                                                                              +1
                                                                                              (del)
                                                                                              0
                                                                                              > Полная аналогия с предупреждениями компилятора — их не должно быть.

                                                                                              С чего бы это? Вот компилятор дурак или просто не учитывает моего стиля кодирования, что мне на другой язык переходить?
                                                                                              +1
                                                                                              Штука про то как 90% людей уверено, что их IQ выше среднего.
                                                                                              Программист или математик сразу увидит неточность (или даже ложность) этого утверждения.
                                                                                              Объяснение для менеджеров:

                                                                                              Математик, скорей всего, скучно заметит вам, что распределение зарплат в организации явно не подчиняется нормальному распределению, а вот способности программистов не ограниченных рамками одной организации — скорей всего будет ближе.
                                                                                              И ваш пример — это вообще расчет средней температуры больных по больнице с учетом морга. И вот он не просто не точен, а явно ложен.
                                                                                                +1
                                                                                                Штука про то как 90% людей уверено, что их IQ выше среднего.
                                                                                                А интернет-опрос показал что 90% респондентов пользуются интернетом.

                                                                                                И ваш пример — явно ложен.
                                                                                                Ошибаетесь.
                                                                                                Задача примера была показать что утверждение «В группе из 100 человек 50 всегда будут выше и 50 — ниже среднего»© не является абсолютом, он это показал.

                                                                                                Математик, скорей всего, скучно заметит вам, что распределение зарплат в организации явно не подчиняется нормальному распределению, а вот способности программистов не ограниченных рамками одной организации
                                                                                                Ага, так и запишем, распределение способностей программистов ограниченных рамками одного опроса подчиняется нормальному распределению и в опросе «из 100 человек 50 всегда будут выше и 50 — ниже среднего»©
                                                                                                  0
                                                                                                  А интернет-опрос показал что 90% респондентов пользуются интернетом.

                                                                                                  Вы в аналогии вообще никак. Особенно с мат.статом, не ваше это.

                                                                                                  В моей (не)шутке базис не ограничен, что указывает именно на проблемы восприятия действительности и реальной оценки своих возможностей людьми.
                                                                                                  У вас же шутка о некорректных условиях опроса.

                                                                                                  Окей, шутка для реальных математиков и физиков: «90% молекул газа считает свою скорость выше средней»
                                                                                                  Задача примера была показать что утверждение «В группе из 100 человек 50 всегда будут выше и 50 — ниже среднего»© не является абсолютом, он это показал.

                                                                                                  Некорректным «доказательством» не получится ничего показать. Это — логика.

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

                                                                                                  Вы серьезно? Вообще-то статистику собирают именно так, стараясь, что бы участники опроса подчинялись общему для всех правилу. В противном случае это будет то, что описали вы в своей шутке про пользованием интернетом. Так что, если вы не отбирали специально 100 самых умных людей на планете на основе предыдущих глобальных исследований IQ, то в среднем скорей всего именно так и получится.
                                                                                                  То есть еще раз: в отдельном конкретном случае спец.выборки может быть не так, да, но в среднем утверждение будет верно. С учетом, что большинство наук изучает именно «среднее» поведение и по сути являются статистическими (как та же физика), то по сути вы сейчас пытаетесь доказать истинность моей шутки про молекулы:
                                                                                                  Теоретически можно отобрать 100 молекул газа так, что бы их распределение было не по максвеллу (взять 10 самых медленных молекул и 90 самых быстрых), однако это никак не опровергнет физику.

                                                                                                  Вот если бы вы усомнились в том, что распределение — обязательно нормальное, тогда да. Но вы изначально взяли заведомо неверную выборку и этим что-то пытались показать. И я как раз с точки зрения математики на это указал.
                                                                                                    +1
                                                                                                    Вы в аналогии вообще никак. Особенно с мат.статом, не ваше это.
                                                                                                    Если Вы не понимаете аналогию, это не значит что «она никак», это значит что Вы ее не понимаете.

                                                                                                    Некорректным «доказательством» не получится ничего показать. Это — логика.
                                                                                                    Естественно. Именно поэтому был приведен корректный контр-пример, показывающий что есть как минимум одна ситуация, когда заявленное правило не работает. Вы правда этого не поняли?

                                                                                                    Вы серьезно? Вообще-то статистику собирают именно так, стараясь, что бы участники опроса подчинялись общему для всех правилу.
                                                                                                    Вы серьезно? Вообще-то статистику по опросам достаточно редко стараются так собирать (по маркетинговым причинам), а даже когда собирают с прицелом на это то все равно это редко получается — т.к. идеальные условия миф.

                                                                                                    Вот если бы вы усомнились в том, что распределение — обязательно нормальное, тогда да.
                                                                                                    Вообще-то об этом сообщение и было. Жаль что Вы этого не поняли.
                                                                                              +1
                                                                                              Сейчас случайно наткнулся на просторах интернета на интересное обсуждение. В общем, количество предупреждений, выдаваемых PVS-Studio постепенно растет и один неравнодушный замечает, что "It seems that bugfixing is going wrong..." :)

                                                                                              Это я просто на примере хочу ещё раз продемонстрировать, что анализатор может показывать менеджеру о некоторых процессах, происходящих в проекте. Как я писал в статье, анализатор кода это не только инструмент для поиска ошибок, но и один из инструментов для контроля и слежения за происходящим. Он позволяет держать менеджеру руку на пульсе проекта.
                                                                                                0

                                                                                                Видимо, разработчиков этой студии стоит поздравить со взятием еще одной вершины: они так задолбали программистское сообщество своей рекламой (оно реально из каждого утюга сейчас), что когда приходят в любую компанию натыкаются лишь на раздражение. Теперь им приходится аппелировать к менеджерам прямо оскорбляя программистов, утверждая, что 90% их — обладатели синдрома Даннинга-Крюгера, а сами они хорошие. Сам я не программист ни разу (пишу немного на питоне), но даже меня, админа, это задолбаоло.

                                                                                                  –2
                                                                                                  Основная причина задалбывания — эти люди считают, что исправление мелких ошибок — это самое главное. В квартире кроватей нет, вместо пола — бетонные стяжки. Сантехника стоит, но дверь в туалет ещё не поставили. И тут эти «заплатите нам и мы втридорога помоем окна». :-)
                                                                                                  0
                                                                                                  Как вы оцениваете свой уровень как программиста (ниже среднего, средний, выше среднего)?
                                                                                                  Настоящий программист спросил бы сначала, как считается среднее?
                                                                                                  Среднее среди всех людей?
                                                                                                  Среднее среди программистов?
                                                                                                  Среднее среди участников конференции по высоконагруженным проектам?
                                                                                                    0
                                                                                                    Может быть есть какая-то sensitivity-specificity статистика анализатора в зависимости от настроек?
                                                                                                    Или это слишком глубоко?
                                                                                                      0
                                                                                                      Не понял вопрос. Прошу уточнить.
                                                                                                        0

                                                                                                        sensitivity-specificity — это про ошибки первого и второго рода; про false-positive и false-negative. Всякие статистики-биологи строят ROC-кривые и считают AUC.

                                                                                                          +2
                                                                                                          Не знаю, что здесь ответить. Не занимались какой-то такой статистикой.
                                                                                                          P.S. Желающие могут брать SonarSource, прицепить наш анализатор и настроить графиков и зависимостей на любой вкус.
                                                                                                            +1
                                                                                                            почему именно статистики-биологи, а не статистики-радио-физики или статистики-экономисты?
                                                                                                              +2

                                                                                                              Особенно популярны ROC-кривые у статистиков-зануд.

                                                                                                                –3
                                                                                                                Моя задача набирать комментарии в разных новых постингах, а не в одном треде у самых злобных троллей хабра. Как вас только сюда вахтёр пропустил…
                                                                                                        +3
                                                                                                        Статья точно для менеджеров, так как не содержит ни одного единорога )) У меня знакомый есть, который почти уговорил менеджеров использовать в проектах PVS Studio, как те зашли на ваш сайт и сказали, что какие-то несерьезные ребята
                                                                                                          +1
                                                                                                          Когда тебя назвали несерьёзным…

                                                                                                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                                                          Самое читаемое