Простая ошибка при кодировании — не значит нестрашная ошибка


    Популяризируя статический анализатор кода PVS-Studio, мы обычно пишем статьи для программистов. Однако, на некоторые вещи программисты смотрят одностороннее. Именно поэтому и существуют менеджеры программных проектов, которые могут управлять процессом развития проекта направлять его в нужное русло. Я решил написать несколько статей, целевой аудиторией которых являются менеджеры программных проектов. Эти статьи помогут им лучше ориентироваться в вопросах использования методологии статического анализа кода. Сейчас мы рассмотрим ложный постулат: «ошибки кодирования несущественны».

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

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

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

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

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

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

    Чтобы не быть голословным, предлагаю вам 3 примера.

    Для начала можно вспомнить критическую уязвимость в iOS, появившуюся из-за двойного goto.

    if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
      goto fail;
    if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
      goto fail;
      goto fail;
    if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
      goto fail;

    Подробности изложены в статье Apple's SSL/TLS bug. Не важно появилась эта ошибка из-за опечатки или неудачного merge. Явно, это «механическая» ошибка, не имеющая отношения к математике или алгоритмам. При этом, подобная ошибка обнаруживается анализатором PVS-Studio.

    Теперь вспомним уязвимость в MySQL: Security vulnerability in MySQL/MariaDB sql/password.c.

    char foo(...) {
      return memcmp(...);
    }

    Ошибка возникает из-за неявного приведения типа (int -> char), при котором отбрасываются значения старших битов. Это вновь ошибка, которая не имеет отношения к сложным алгоритмам и прекрасно выявляется анализатором PVS-Studio. Не смотря на свою простоту, ошибка приводит к тому, что на некоторых платформах в 1 случае из 256 процедура сравнения хэша с ожидаемым значением всегда возвращает значение 'true', независимо от хэша.

    Третий пример. Я участвовал в разработке пакета численного моделирования газодинамических процессов. Масса математики, алгоритмов и т.д. И, конечно, были связанные с этой математикой ошибки и проблемы. Однако, мне намного больше запомнились проблемы, возникающие из-за переноса кода на 64-битные системы. Кстати, именно тогда и зародилась идея создать анализатор Viva64, который потом развился в PVS-Studio (история: как 10 лет назад начинался проект PVS-Studio).

    Одна из ошибок была связана с неправильным позиционированием в файле с помощью функции _fseeki64. Пакет моделирования, став 64-битным, смог обрабатывать больший объем данных и, как результат, записывать данные большего объема на диск. Вот только потом, не мог их правильно прочитать. Причем, нельзя сказать, что код был написан как-то уж очень плохо. Приблизительно там было так:

    unsigned long W, H, D, DensityPos;
    ....
    unsigned long offset = W * H * D * DensityPos;
    res = _fseeki64(f, offset * sizeof(float), SEEK_SET);

    Возникает переполнение при перемножении переменных. В защиту программиста можно сказать, что, когда он писал этот код, сложно предположить, что в Win64 (ILP32LL) размер типа long останется 32-битным. Эту ошибку искали очень долго. Когда приводится вот такой псевдокод, кажется всё простым и понятным. На практике же, очень сложно было понять, почему при превышении определенного порога объёма обрабатываемых данных, начинаются странные ошибки. Неделю отладки легко можно было бы заменить проверкой кода с помощью PVS-Studio, который в два счёта нашел бы описанный баг. Алгоритмы и математика при переходе на 64-битную систему как раз не повлекли за собой никаких сложностей.

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

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

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

    Дополнительные ссылки:

    1. Страница PVS-Studio.
    2. Мифы о статическом анализе. Миф первый – статический анализатор это продукт разового применения.
    3. Мифы о статическом анализе. Миф второй – профессиональные разработчики не допускают глупых ошибок.
    4. Мифы о статическом анализе. Миф третий – динамический анализ лучше чем статический.
    5. Мифы о статическом анализе. Миф четвёртый – программисты хотят добавлять свои правила в статический анализатор.
    6. Мифы о статическом анализе. Миф пятый – можно составить маленькую программу, чтобы оценить инструмент.
    7. В дополнении к пятому мифу: Почему я не люблю синтетические тесты.



    Если хотите поделиться этой статьей с англоязычной аудиторией, то прошу использовать ссылку на перевод: Andrey Karpov. If the coding bug is banal, it doesn't meant it's not crucial
    PVS-Studio 389,11
    Ищем ошибки в C, C++ и C# на Windows и Linux
    Поделиться публикацией
    Похожие публикации
    Комментарии 91
    • +8

      Да об обычный if (a=b) вместо if (a==b) сколько копий сломано, что уж говорить о чем-то более сложном.

      • –1
        Тот, кто отключил диагностику этого случая в компиляторе — сам себе злобный буратино.

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

        if (...);
        {
            // do smth    
        }
        
        • +2

          но ведь же -Wall (а точнее -Wempty-body) явно скажет, что "warning: if statement has empty body"...

          • 0
            Не на всех версиях компилятора, увы
            • 0
              Вот потому у нас и пяток разных компиляторов.
        • +1
          Недавно я написал статью "Статья о статическом анализе кода для менеджеров, которую не стоит читать программистам". Вполне закономерно к ней начали оставлять комментарии о том, что нет пользы от инструмента поиска простых ошибок. Приведу один из таких комментариев:

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


          А причем тут остальные программисты и "закономерно"?

          • +1

            Причем, как уже вам написали, в 99% случаев причиной для того, что бы не использовать инструменты статического анализа является менеджер — "нет денег", "это все глупость", "вот выкатим релиз/второй релиз/… и займемся анализом" и так далее.

            • 0
              Закономерно, что обязательно есть кто-то, кто скажет «не нужно».
              • +1

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


                Аналогичная ситуация с юнит-тестами, ООП, паттернами и розовыми поняшками. Мне кажется странным делать из этого причину для отдельной статьи.


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

                • –1
                  Точнее — не выгодно. Критерий выгоды вам уже писали, вроде он был 1 день труда разработчика в месяц. Поскольку цена на PVS-studio секретна, только вы сами можете назвать количество разработчиков, при которых цена начнет оправдываться.
                • +1
                  Не совсем понятно, к чему популизировать миф, как будто все программисты против статического анализа или ненавидят его?
                  Так маркетинг. Вы посмотрите контекст последних статей.
                  «Наш анализатор необходим каждому, а программисты возражают против него просто из вредности, боязни и т.д… Купи анализатор, докажи что ты круче программиста, поставь засранца на место»:)
                  • 0

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

                    • 0
                      Купи анализатор, докажи что ты круче программиста, поставь засранца на место»

                      Кстати, в этом что-то есть. Я не призываю так поступать, однако иногда умелое использование такой методики пожалуй может дать воспитательный эффект. :)
                      • +1

                        Проблема в том, что:


                        1. индюки и без того в этом уверены,
                        2. большая часть из тех, кто всё-же захочет опустить (к счастью таких не очень много) будет пытаться добиться инфы "а как опустить", потому что сам с инструментом не справится
                        3. остальные деляется на четыре подкатегории
                          а программисты им уже устали объяснять, как полезен стат. анализ
                          б у проекта нет средств
                          в они уже купили инструмент стат.анализа
                          г программисты продавили использования опен-сорсных решений стат. анализа (это больше касается java, возможно в каких-то ещё экосистемах есть качественные оперсорсные решения стат.анализа).

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

                    • +1
                      как будто все программисты против

                      Странно, написано вроде понятно, но вы при этом умудрились прочитать исключительно то, что захотели.
                      Давайте начнем с самого простого с точки зрения логики. Покажите в посте кусок текста, из которого возникают ваши «все программисты»?
                      • +1

                        Например


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

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


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


                        Где все эти программисты?


                        Возможно, я предвзят, но у меня сложилось впечетление, что это определенно попытка популяризации какого-то странного мифа про программистов.

                        • 0
                          Где все эти программисты? Возможно, я предвзят, но у меня сложилось впечатление, что это определенно попытка популяризации какого-то странного мифа про программистов.
                          К сожалению, их много. Если у вас есть пара недель свободного времени предлагаю прочитать все комментарии, ко всем нашим статьям в блоге. Вы увидите, что я пишу это от того, что «наболело».
                          • 0

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


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


                            Или я не прав, и находятся люди, которые утверждают, что статический анализ бесполезен для любых проектов?)

                          • +1
                            И вам тоже, сравните
                            как будто все программисты против

                            многие программисты

                            Многие != всем. Многие != большинству.
                            Многие — это просто какое-то заметное количество людей. Больше одного и однозначно меньше 100%.
                            Из-за нее складывается впечетление, что большинство профессиональных

                            Поэтому, когда кажется — крестится стоит.
                            на основе комментариев одного человека

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

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

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


                              Многие — это должно быть достаточно весомое количество. Я понимаю, когда говорят, что многие программисты выступают против TTD, я вижу, их мнение доходит до Хабра, например.


                              А кто те многие, которые выступают против статического анализа?


                              Загуглив "статический анализ не работает" я не могу найти статьи, которые бы говорили против него, найти такое же для TDD не составит труда.


                              Так кто эти "многие"?

                              • 0
                                А кто те многие, которые выступают против статического анализа?
                                Я видел их в комментария, в почте. Но я никогда не собирал ссылки на такие дискуссии, поэтому не могу сейчас достать список «100 примеров». В общем с пруфами затруднение и даже как поискать не знаю. С ходу только вспомнилась заметка "Народ против PVS-Studio: дубль первый" с выводом в конце: не следует полагаться на анализаторы, скорее нужно просто повысить свой уровень профессионализма. Формально вывод правильный, но при разборе статьи выясняется, что автор просто не разобрался в вопросе.
                                • 0

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


                                  На мой взгляд, выступать против можно так: Исследование, в котором говорится, что TDD не работает


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

                                • 0
                                  Вы делаете абсолютно так же, когда утверждаете, что «статический анализ в каждый проект».

                                  А можете уточнить, где? Где это делаю я? Именно я, м?
                        • +1
                          Статический анализатор — вещь хорошая. Пользовался продуктом от HP.
                          К сожалению часты ложные срабатывания.

                          Проблема использования статических анализаторов одна — деньги:
                          Менеджеры не дают денег, а компании разрабатывающие такие продукты хотят очень много денег (от части обоснованно, т.к. алгоритмы довольно сложные, а задача нетривиальная).
                          Вообще статический анализ должен стать частью IDE — может быть когда-нибудь увижу его в Visual Studio.

                          По поводу приведённых примеров — это скорее всего результат работы неопытных разработчиков, т.к. большинство опытных знают, что if лучше не использовать без { }. А все остальные примеры актуальны только для C++, т.к. в Java или C# либо компилятор не позволит такое сделать, либо просто нет необходимости манипуляции на уровне байтов.
                          • +2
                            Вообще статический анализ должен стать частью IDE — может быть когда-нибудь увижу его в Visual Studio.

                            PVS-Studio есть для Visual Studio (скрины), так же там есть стандартные простые статические анализаторы для C++ и C#, или что вы имели ввиду?
                          • 0
                            А статический анализ и так есть в любом компиляторе. Точнее его самая важная часть — 95% наиболее полезных диагностик. Любой статнализатор — это гонка за оставшимися 3-5 процентами.
                            • +1
                              Вы сильно преувеличиваете. К сожалению, подтвердить свои слова я не могу. Для этого нужен проект, который разрабатывался с ключём -w0 (т.е. без предупреждений). Тогда бы можно было запустить компилятор и анализатор и сравнить результаты. Я предполагаю, что анализатор найдет как минимум в 2-3 раза больше, чем компилятор. Однако, тут никаких пруфов нет: только Ваше мнение против моего.
                              • –3
                                Ну тогда обратите внимание, что 100% приведенных вами в данной статье примеров — обнаруживаются компиляторами.

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

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

                                Сделайте тест на своем проекте. Напишите тысячу строк кода без компиляции. И посмотрите число ошибок, которые даст компилятор при -Wall -Wextra и PVS-Studio.

                                • +1
                                  Это исключительно Ваше мнение, основанное на желании убедить себя и других, что статический анализ не нужен. У меня другое мнение, основанное на опыте и желании продать анализатор :). Спор бесперспективен.
                          • 0
                            Причина простая: основные баги — в алгоритмах. В работе аналитиков, математиков, постановщиков, алгоритмистов. А багов при кодировании — не так много.

                            Вы уводите дискуссию в другой русло. Jef239 весь исходный пост пытался добиться ответа на вопрос: при каких условиях внедрение PVS-Studio окупится? Единственная внятная метрика, которую вы указали: размер проекта, минимум (условный) 250,000 Lines of Code.

                            Судя по текущей статье, добавляется еще одна метрика: проект должен быть уровня iOS или MySQL (подозреваю, в такого роде проектах уже есть 250k LoC).

                            Вы можете предложить еще какие-то параметры оценки окупаемости PVS-Studio?
                            • 0
                              я чуть ниже написал список вопросов и возможные варианты ответов.
                            • +1
                              А в C/C++ библиотеках разве нет таких констант, которые содержат размер типов данных на текущей платформе? Это вместо того, чтобы гадать — будет или не будет long 32-битный.
                            • 0
                              Вы несколько переврали то, о чем я писал. Основные вопросы:

                              1. Когда статический анализ начинает оправдывать время, затраченное на разбор его предупреждений?
                              2. Когда PBS-Studio начинает оправдывать свою цену?
                              3. Когда покупка PVS-Studio становится выгоднее иных мер?
                              4. Когда багфиксинг становится выгоднее развития проекта? То есть появляется смысл сокращать технический долг, а не накапливать его?
                              5. Когда поиск потенциальных ошибок важнее исправления реально проявляющихся ошибок?


                              На первый вопрос есть ответ про 250КLoc.

                              На второй — есть гипотеза, что это происходит когда ФОП за 1 день в месяц всех девелоперов (12 дней в год) становится больше цены PVS-Studio. Видимо это означает от пары сотен разработчиков.

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

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

                              На пятый — видимо речь о специальных областях с большими рисками. АСУТП, банковские приложения, космос и так далее — везде, где можно потерять миллионы долларов. Разумный критерий — если цена скрытой ошибки больше, чем в сто раз превышает стоимость статанализатора — его есть смысл применять.

                              А на то, что вы написали — отвечу чуть позже.
                              • +1
                                Такого расчета нет и не будет в силу его сложности. Слишком много факторов и субъективных мнений которые невозможно учесть. Сейчас я приведу аналогию.

                                Перед вами стоит задача купить 10 компьютеров для нового отдела программистов. Вы не будете делать никакой расчет по оценки окупаемости. Вот как оценить нужно купить мышку за 300 или 400 рублей? Первая дешевле, но вторая надежнее. Как выбрать? Проводить опрос у программистов, читать обзоры? А монитор — 22 или 25 дюймов? Что лучше? Первый дешевле, а второй показывает больше кода и программисты возможно будут работать быстрее. Как посчитать окупаемость для монитора? А стоит экономить на памяти или нет? А наушники нужны для большего комфорта или обойдутся без них?

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

                                Так как же тогда выбирают компьютеры для команды программистов? По ощущению. Вот тоже самое получается и со статическим анализом. Он или нужен или нет. Или чувствуется потребность или нет. Ибо что с компьютерами, что со статическим анализатором траты на зарплаты не соизмеримо больше.
                                • 0
                                  С компьютерами как раз все просто. На кривой цена-параметр у каждого компонента есть изгиб. До этого изгиба небольшое изменение цены сильно увеличивает параметр, после — для увеличения параметра нужно сильное увеличение цены. Вот вблизи изгиба и выгодней всего покупать.

                                  А от вас я жду не расчета, а оценки. Если вы не имеете такой оценки — значит вы не имеете образа покупателя и не понимаете, кто ваш клиент, а кто нет.

                                  Отсюда — и те заявления, что меня раздражают своей всеобщностью.

                                  А заказчику перед покупкой все равно приходится такой анализ сделать. Если покупка компа в любом случае выгодна и речь идет о процентах, то станализатор вполне может не окупиться. Ну например в моем случае (до 50КLoc в основном проекте) — килобаксы за PVS-studio не окупятся.
                                  • +2
                                    На кривой цена-параметр у каждого компонента есть изгиб

                                    Пруф будет? С кривыми по каждому компоненту.
                                    Или вы только что доказали предыдущее утверждение, что подбор конфиги идет на глазок.
                              • 0
                                Мне не нравится, что вы передергиваете.

                                Опять мы встречаемся с мифом, что профессиональные разработчики не допускают простых ошибок.

                                Допускают. Ещё как допускают — компилятор каждый день мне говорит об этом. Но:

                                1. Ошибки бывают как в кодировании, так и в алгоритмах, матметодах, менеджменте (я про мисфичи)
                                2. Большую часть ошибок кодирования находит компилятор.
                                3. Статанализатор находится лишь часть ошибок, оставшихся после компияции.


                                Пример из РД 50-25645.325-89:

                                image

                                Запятую вместо точки в коде мне найдет компилятор. А кто найдет + вместо — (реальная ошибка в ИКД ГЛОНАС)? А если 1 вместо 7?

                                А вот любимый пример мисфичи. Несмотря на максимально жесткое тестирование авионики просто забыли включить функциональность в результирующий проект. Примерно аналогичная ошибка похоронила 3 спутника ГЛОНАСС. Там изменили размеры бака, но ни расчетчики, ни QA этого не поняли.

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

                                В итоге получается примерно так. 40% ошибок — это кодирование. Из них 70% ошибок (28% всех ошибок) находит компилятор. Из оставшихся 12% ошибок статанализ находит 3-5%. То есть — 0.4-0.6% общего числа ошибок находятся статаналиом.

                                Понятно, что цифры — условные, жду от вас вашей собственной оценки.

                                Ну и о ваших примерах. goto fail вне if — ну так dead code находится компилятором. Это как раз та часть статанализа, которую компиляторы обычно умеют. Неявное приведение типа с обрезанием значимой части — опять диагностируется компиляторами. Третий пример — целочисленное переполнение. И опять — зачастую компиляторы это умеют, правда не статически, а динамически.

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

                                Ну а о том, что компилировать надо с -Wall -Wextra — никто не спорит.
                                • +2
                                  Не вижу смысла вдаваться в споры. Вы столь критически настроены, что всё равно не хотите воспринимать, что компиляторы весьма слабо анализируют код, выдавая при этом слишком много ложных срабатываний. И именно поэтому всякими -Wall -Wextra мало кто пользуется. Неудобно!

                                  Если бы это было не так, не было этой базы с 11000 ошибками.

                                  И именно поэтому статические анализаторы такие как PVS-Studio или Coverity были, есть и будут. Они всегда идут на шаг или два впереди компиляторов в плане диагностик.

                                  Увлекаясь критикой стат. анализторов, Вы начинаете приписывать компиляторам магические возможности, которых нет. Например, так дело обстоит с целочисленным переполнением. Эта и подобные ошибки положили начало созданию Viva64, который со временем превратился в PVS-Studio. И искать подобные ошибки компиляторы не умели, не умеют и не собираются учиться. Что-бы не быть голословным, буквально на днях у нас появился новый клиент, купивший лицензию на PVS-Studio ради 64-битных диагностик. Именно ради них! Видимо пришло делать 64-битнео приложение, а оно не работает… :)
                                  • +1
                                    Про 64биты — вы правы. Там действительно более чем хватает проблем с переходом. Или собственный колхоз на регулярных выражениях — или покупка готового.

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

                                    -fsanitize=signed-integer-overflow
                                    This option enables signed integer overflow checking. We check that the result of +, *, and both unary and binary - does not overflow in the signed arithmetics.

                                    Это такая особая рантаймовая магия. Но знание — сила, а незнание — силища богатырская. Знали бы про неё — не было бы PVS-Studio. Но ничего нового в ней нет — эта технология применяется в компиляторах года с 1965ого.Расставляются инструкции условного перехода по установленному carry-биту, остальное делает рантайм.

                                    Они всегда идут на шаг или два впереди компиляторов в плане диагностик.

                                    Согласен. Личный самолет — круче велосипеда. Вот только покупают его единицы.

                                    компиляторы весьма слабо анализируют код, выдавая при этом слишком много ложных срабатываний. И именно поэтому всякими -Wall -Wextra мало кто пользуется. Неудобно!

                                    Не так уж и много, 10% хинтов и 50% варнингов — это реальные ошибки. А вот у cppcheck — 99% — не по делу.

                                    А вот clang static analyzer хочется попробовать. Если скажите, где найди виндовую сборку — буду рад. СУдя по вашей же статье — он похож на лучший из бесплатный.
                                    • 0
                                      -fsanitize=signed-integer-overflow

                                      Ну-ну… Попробуйте искать так ошибки в большом проекте. Да и вообще, никто не обещал, что переполнение будет целочисленным. Я же написал:
                                      unsigned long W, H, D, DensityPos;
                                      ....
                                      unsigned long offset = W * H * D * DensityPos;
                                      res = _fseeki64(f, offset * sizeof(float), SEEK_SET);
                                      
                                      • 0
                                        И что тут не целочисленное? Может вы имели ввиду знаковое?
                                        • –1
                                          Да. Опечатался:

                                          Да и вообще, никто не обещал, что переполнение будет знаковым.
                                          • –1
                                            Тогда у вас ошибка была ещё до перехода к 64битности. В fseek второй параметр long и компилятор должен был предупредить, что вы ему подсовываете unsigned long.

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


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

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

                                  P.S. При разумных ценах — прогнозирую бешеный успех.
                                  • +2
                                    Вряд ли взлетит. Все-таки стат анализ нужен не разово, а постоянно. Это как с тестами: написать их один раз полезно, но обычно слишком затратно, пользу они начинают приносить позже, когда показывают не сломалось ли чего после новых изменений. Вряд ли много компаний будут готовы платить за разовое применение анализатора столько, сколько при такой модели заработка будут просить разработчики этого анализатора. Хотя без конкретных цифр сложно сказать наверняка, ситуации разные бывают.
                                    • –3
                                      Польза разовой проверки для клиента понятная — это ачивка «проверено, мин нет». С другой стороны — это аутсоринг. А аутсоринг обычно выгоден обоим сторонам. Но для этого нужна автоматизация и в оплате договоров и в проверке. То есть — SaaS. Собственно так работает один из тяжелых анализаторов (вроде coverity).

                                      Польза для производителя тоже понятна — это подкормка рыбы перед подсчечкой. Во время SaaS выясняются финансовые возможности клиента и особенности его софта.

                                      А вот какую модель ценообразования они выберут… Письмо я написал, в ответ «да и нет не говорите, черное и белое не называйте». О цене — молчат как партизаны на допросе. Будем считать это вежливым отказом в обслуживании.

                                      Для SaaS ценообразование понятное — в основе экономия времени клиента на установку бесплатной версии. То есть несколько дней ФОП девелопера. Дальше это все множится на жадность производителя (с учетом выгоды от обнаружения ошибок).

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

                                      • 0
                                        Вряд ли взлетит. Все-таки стат анализ нужен не разово, а постоянно.
                                        Мы думаем, такие проверки могут быть хорошим способом познакомиться и продемонстрировать возможности PVS-Studio. А даже если дальнейшее сотрудничество не сложится, в программе станет меньше багов, что тоже хорошо.
                                        • +1

                                          ИМХО нужно популяризировать статический анализ, в том числе и как SaaS, и сделать его доступным, скажем, инди-студиям за пару тыщщ деревянных за запуск. Они будут пользоваться им раз в полгода, найдя все опечатки, потом подсядут, а то и лучше кодить начнут — особенно если из-за какого-нибудь интересного бага, который не вылавливается силами программистов по какой-либо причине, но ловится стат.анализатором, придется его запустить, после чего какой-нибудь git blame покажет, кто сделал этот баг, и с него полетят денежки. Денежный стимул — самый серьезный в современном мире "волшебный пендаль". Если вы сможете (вопрос, к сожалению, сложный — для проверки проекта потребуется реально развернуть весь проект со всеми сторонними библиотеками, если я правильно понимаю механизм работы PVS-Studio) предоставить статический анализ как услугу, мне кажется, она будет востребована довольно большим числом людей, чтобы появилась достаточная для окупаемости конверсия.

                                          • 0

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

                                    • 0
                                      Нигде не нашел информации о типе поддерживаемых проектов. Работает ли PVS с проектами ASP.NET MVC Core (вместо файла проекта project.json)?
                                      На днях ради интереса скачал и запустил ваш плагин на одном своем проекте, но на любые попытки анализа PVS ругается, что это не C++ или C# проект. Такое впечатление, что он не видит стандартного файла проекта и больше ничего делать не хочет.

                                      P.S. В поддержку писать не стал, т.к. интерес чисто академический.
                                      • +1
                                        Плагин PVS-Studio поддерживает проекты форматов vcxproj\csproj. Касательно ASP.NET, Microsoft отказалась от поддержки json\xproj в последней версии ASP.NET (подробно про это можно почитать здесь). На момент выхода Roslyn 1.0, xproj ещё не поддерживался в Roslyn, а когда мы обновили C# анализатор до Roslyn 2.0, об отказе от поддержки xproj уже стало известно, поэтому мы решили не добавлять поддержки для этого типа проектов. ASP.NET проекты на csproj должны проверяться.
                                        • +2
                                          Да, верно у меня проект .xproj / project.json. Статью по вашей ссылке читал еще раньше. Странно, но VS 2015 Update 3 именно такие проекты и создает (если выбрать ASP.NET Core).

                                          Но все равно, спасибо что подтвердили мою догадку.
                                          • 0
                                            Странно, но VS 2015 Update 3 именно такие проекты и создает (если выбрать ASP.NET Core).

                                            Начиная с VS2017 такой тип проектов использует уже csproj. К сожалению, пользователи ASP.NET Core на VS2015 у нас пока-что выпали из поддержки.
                                      • 0
                                        Решил немного развить мысль про аудит кода и других услуг: Команда PVS-Studio: аудит кода и другие услуги.
                                        • 0
                                          А с помощью чего вы анализируете/проверяете JAVA проекты? (Как разовый, так и регулярный аудит вашего кода (C, C++, C#, Java).)
                                          • –1
                                            Java — стороннеми инструментами, на которые указал заказчик.
                                          • –1
                                            Цен все равно нет и так просто их не получить.

                                            Более того, в эксперименте не удалось даже понять масштаб цен.
                                          • –8

                                            PVS-Studio соткан из противоречий.
                                            Рекламирует себя как B2B но почему-то в виде массового спама статьями на хабре.
                                            Уступает Coverity по глубине анализа, а решарперу по всем прочим пользовательским характеристикам сразу.
                                            Как результат — ниша очень дорогого дополнения к имеющемуся инструментарию, чья единственная ценность в правилах, которые не покрывает решарпер.
                                            Прибыльность такого бизнеса столь же загадочна как и цена продукта.

                                            • 0
                                              а что, решарпер могет в C/C++?
                                            • 0
                                              решарпер
                                              Не стоит смешивать статические анализаторы кода и productivity tools. Статический анализ это подробная документация по всем диагностикам, поддержка и консультирование, это интеграция с IncrediBuild, это Standalone, это инструменты интеграции в большой проект (например, база разметки сообщений), отслеживание запусков компилятора (CLMonitoring), рассылка писем и т.д.
                                              • –5

                                                Не стоит дезинформировать читателей:


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

                                                Я надеюсь, вы знаете, откуда эта конкретная цитата. Этому определению решарпер полностью удовлетворяет.


                                                Википедия:


                                                Стати́ческий ана́лиз ко́да (англ. static code analysis) — анализ программного обеспечения, производимый (в отличие от динамического анализа) без реального выполнения исследуемых программ

                                                И этому определению решарпер полностью удовлетворяет.


                                                Сайт JetBrains:


                                                Статический анализ качества кода и автоматическое исправление обнаруженных проблем
                                                Для всех поддерживаемых языков ReSharper распознает ошибки компиляции, времени выполнения и логические ошибки, а также избыточные и неоптимальные конструкции, и подсвечивает обнаруженные проблемы прямо в редакторе. Более тысячи инспекций, которые ReSharper использует для поиска проблем в коде, позволят мгновенно увидеть все потенциально опасные места в текущем файле или даже во всем решении Visual Studio. Для большинства из них ReSharper предложит один или более вариантов автоматического исправления.

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

                                                • +1
                                                  Использование ReSharper не мешает находить нам ошибки в C# проектах.

                                                  Что касается C++ то, я заявляю, что PVS-Studio лучше многих анализаторов кода (ReSharper, Cppcheck, ...). Наступаем на пятки и в ближайшее время превзойдём по многим направлениям Coverity и Klocwork. Я знаю, что PVS-Studio крут и мы регулярно это показываем на практике. Если кто-то хочет опровергнуть, пусть попробует доказать обратное.
                                                  • –2
                                                    Использование ReSharper не мешает находить нам ошибки в C# проектах.


                                                    Andrey2008 вы гарантируете, что использование PVS-Studio позволит забыть о диагностиках выдаваемых R#?
                                                    • +3

                                                      @Andrey2008 этого и не утверждал.
                                                      Со своей стороны могу точно сказать, что статическим анализом решарпера пренебрегать нельзя. Например, несколько классов с дефектами из статьи по ссылке он справедливо предлагает выкинуть как неиспользуемые.
                                                      Ну и результаты выдает в реальном времени прямо в студии

                                                      • 0
                                                        В соседней ветке Jef239 гарантирует, что если использовать компилятор, то можно забыть о статических анализаторах…

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

                                                        И R# не статический анализатор, а большая большая надстройка с горой функционала, среди которого анализ кода далеко не основная задача, а совсем малая часть. И вообще Вы можете найти много негативных отзывов о производительности R# при разработке, и сами разработчики это знают, поэтому ограничены в возможностях. PVS-Studio же занимается только статическим анализом, что за тоже самое время позволяет получить совсем другое качество анализа.
                                                        • –1
                                                          И R# не статический анализатор

                                                          Да неужели?
                                                          Решарпер умеет много чего еще, но собственно статическим анализом (по определению с вашего же сайта!) занимается в первую очередь.
                                                          Почему вы отрицаете очевидное?


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

                                                          У решарпера имеются проблемы с производительностью на больших проектах в реальном времени. Насколько мне известно PVS Studio в таком режиме вообще не работает.


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

                                                          Время на что именно сравнивалось и где?

                                                          • 0
                                                            И R# не статический анализатор

                                                            Да неужели?

                                                            Именно так, статический анализ одна из возможностей, как и у компилятора.
                                                            ReSharper (R#) — дополнение (плагин), разработанное компанией JetBrains для повышения продуктивности работы в Microsoft Visual Studio.

                                                            ReSharper повышает эффективность разработки в Microsoft Visual Studio и помогает автоматизировать большинство рутинных процедур.

                                                            А теперь представьте, если всё это выкинуть и заняться только глубоким статическим анализом, будет совсем другой эффект.
                                                            • +1
                                                              Именно так, статический анализ одна из возможностей, как и у компилятора.

                                                              С точностью до наоборот. Вы почему-то трактуете включение как исключение.
                                                              А между тем и компиляторы, и решарпер являются статическими анализаторами и более того, активно используются в этом качестве.
                                                              И без сравнения с ними никакому иному статическому анализатору (PVS Studio) не обойтись.


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

                                                              Мне не нужно ничего представлять, мне нужен конкретный результат. Если вы заявляете что PVS Studio быстрее решарпера, то покажите где и насколько (этого я не видел). Если заявляете что анализирует глубже — покажите случаи, когда PVS Studio находит ошибки, которые не по зубам решарперу (это я сделал за вас).
                                                              Ответы "X (делающий статический анализ) не статический анализатор" для вашего продукта скорее вредны чем бесполезны.

                                                          • +1
                                                            Я писал мягко говоря другое. Время, потраченное на -Wall -Wextra оправдывается. Сводя предупреждения компилятора к нулю мы выигрываем больше, то время, которое мы теряем. А вот время, потраченное, чтобы свести к нулю все предупреждения cppcheck не оправдывается.

                                                            PVS-studio скорее всего оправдает потраченное на разбор время, но не оправдает те килобаксы, за которые он продается.

                                                            А пиратить продукт российских коллег просто не хочется.
                                                        • +3
                                                          Использование ReSharper не мешает находить нам ошибки в C# проектах.

                                                          Очень хорошая иллюстрация к вашим тезисам.
                                                          Я чисто для проформы скачал этот проект себе и проверил решарпером.
                                                          Результаты (сравнение про найденным дефектам из вашей статьи):


                                                          1. Ошибку с безусловной рекурсией и переполнением стека решарпер успешно находит.
                                                          2. Ошибку с TimeSpan.Seconds решарпер не нашел.
                                                          3. Пропущенное значение в switch решапер нашел.
                                                          4. Отсутствие использования значения чистой функции Except решарпер нашел.
                                                          5. Про отрицательное значение в методе Substring у вас ложное срабатывание во всех трех случаях, причем для понимания этого факта в первом случае достаточно посмотреть на строку выше от цитаты.


                                                                    if (!identityEntry.StartsWith("/")) return null;
                                                                    var indexOfEquals = identityEntry.IndexOf("=");
                                                                    if (indexOfEquals < 0) return null;
                                                            
                                                                    var key = identityEntry.Substring(1, indexOfEquals - 1);

                                                            После первой строки в IdentityString первый символ всегда слеш по построению и IndexOfEquals никогда не будет равен нулю.Остальные два случая полностью аналогичны.


                                                          6. Для операции ?? решарпер точно так же определяет что первый аргумент не может оказаться null
                                                          7. Всегда ложное значение условия в if решарпер пропустил.
                                                          8. Возможность словить NRE в данном случае решарпер пропустил.

                                                          Итоги:


                                                          1. Решарпер для статического анализа кода в Orchard или не используется вообще или это делается заведомо неправильно.
                                                          2. PVS Studio находит реально опасные дефекты, которые не обнаруживает решарпер.
                                                          3. Польза от использования конкретно PVS Studio есть, но авторы инструмента допускают наличие дезинформации (уверен, что непреднамеренной) в своих материалах.
                                                          4. Решарпер может и должен использоваться в том числе как статический анализатор кода.
                                                          • 0

                                                            Для полноты картины: вы он-лайн проверки смотрели или полный набор включали и им анализировали?

                                                            • 0

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

                                                  • +5

                                                    Пропустил статью :-) Мне регулярным евангелизмом статического анализа лень заниматься, так что дарю вам ещё довод, раз уж вы занимаетесь. Ошибку вам может внести сама IDE, если быть невнимательным. Пусть у вас такой Java-код:


                                                    void processList(boolean flag, List<String> list) {
                                                        if(flag) {
                                                            if(list.isEmpty()) return;
                                                            if(list.get(0).equals("foo")) {
                                                                System.out.println("...some long processing...");
                                                                // ... many lines of code
                                                            }
                                                        } else {
                                                            if(list.size() < 3) return;
                                                            if(list.get(0).equals("bar")) { // курсор здесь
                                                                System.out.println("...another long processing using "+list.get(0));
                                                                // ... many lines of code
                                                            }
                                                        }
                                                    }

                                                    С этим кодом всё нормально, ошибок нет. Вы его когда-то написали целиком с нуля, а так как вы профессиональный программист, то ошибок вы не допускаете. Но посмотрев на код уже после написания, вы замечаете, что как-то list.get(0) повторяется в соседних строчках, некрасиво. Надо бы в переменную вынести. Вы активируете соответствующий рефакторинг в IDE, встав на это выражение. IDE вас спрашивает: «вам только это вхождение заменить на новую переменную или все?» Вы, естественно, говорите, все, и IDE генерирует такой код:


                                                    void processList(boolean flag, List<String> list) {
                                                        String firstElement = list.get(0);
                                                        if(flag) {
                                                            if(list.isEmpty()) return;
                                                            if(firstElement.equals("foo")) {
                                                                System.out.println("...some long processing...");
                                                                // ... many lines of code
                                                            }
                                                        } else {
                                                            if(list.size() < 3) return;
                                                            if(firstElement.equals("bar")) {
                                                                System.out.println("...another long processing using "+ firstElement);
                                                                // ... many lines of code
                                                            }
                                                        }
                                                    }

                                                    И код стал некорректным, потому что было ещё одно вхождение list.get(0) в другой ветке и IDE его тоже вынесла в переменную, создав её до необходимых проверок на длину списка. Если слишком довериться IDE и не обратить внимания на то, что она сделала, можно здорово обжечься. Я недавно написал диагностику, которая отлавливает статически такой код. В нашем проекте нашлось несколько мест, где он появился именно в результате применения рефакторинга.

                                                    • +3
                                                      Классный пример, Тагир! Хорошо иллюстрирует ситуацию, почему автоматическое исправление «в лоб» не всегда правильно. Ведь многие предлагают, чтобы анализаторы сами правили ошибки.
                                                      • +1

                                                        Правильно, я тоже предлагаю. Надо просто понимать, что автоматический исправлятор тоже может накосячить. Голову отключать никогда не надо и весь свой код перечитывать перед коммитом обязательно. Ну и статический анализ использовать — он заметит то, чего вы не заметите :-)

                                                        • 0

                                                          Вот, кстати, похожий конкретный пример из реального кода. Было:


                                                          if (elements.length > 0 && matchContext.getPattern()
                                                                  .getStrategy().continueMatching(elements[0].getParent())) ...

                                                          Стало:


                                                          PsiElement parent = elements[0].getParent();
                                                          if (elements.length > 0 && matchContext.getPattern()
                                                                  .getStrategy().continueMatching(parent != null ? parent : elements[0])) ...

                                                          Так как захотели elements[0].getParent() переиспользовать, вынесли в переменную с помощью автоматического рефакторинга. Но так как посреди условия нельзя объявить переменную, IDE объявила её перед условием, в том числе перед важной короткозамкнутой проверкой elements.length > 0. Думаю, если б человек вручную переменную создал, он бы заметил проблему.

                                                          • 0
                                                            Да, здесь бы человек «обыграл» «тупую машину» :-)
                                                            • 0
                                                              Думаю, если б человек вручную переменную создал, он бы заметил проблему.

                                                              Наблюдал кучу различных ошибок копи-пасты и прочих рефакторингов. И вот знаете, что-то сомнения берут, что человек обязательно бы заметил проблему… С вероятностью эдак 80-90% пропустил бы, имхо.

                                                              • 0

                                                                О, мнения разошлись :-) Я всё же с вами не соглашусь. Когда человек пишет что-то руками, он существенно больше внимания обращает на то, что пишет.

                                                              • 0

                                                                В таких случаях проверку на длину лучше вынести отдельно, примерно так:


                                                                if (elements.length == 0)
                                                                   return;

                                                                И для остальных проверок границ поступать аналогично. Такой код и читается проще и авторефакторинги с ним лучше дружат.

                                                                • 0

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

                                                                  • 0
                                                                    В принципе это всё сигнализирует, что хорошо бы весь метод порефакторить и разбить на более мелкие, но в реальной жизни не бывает так, что весь код выглядит идеально.

                                                                    Выделение метода делается в три клика: такие рефакторинги из области чистки зубов и их цена однозначно перекрывается улучшением читаемости кода. Тут лучше не лениться, а следовать правилу бойскаута.

                                                                    • 0

                                                                      Это если возвращаемое значение в блоке кода одно и нет нелокального control flow. А если нет? Extract method object обычно генерирует результат далёкий от оптимального. И даже если и с возвращаемым значением всё нормально, сигнатура результирующего метода может оказаться перегруженной и запутанной. Чтобы сделать всё красиво, зачастую всё равно думать приходится. Да и не весь код в мире написан в те годы, когда в IDE Extract method уже хорошо работал.

                                                                      • 0
                                                                        Это если возвращаемое значение в блоке кода одно и нет нелокального control flow.

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

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

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