Комментарии 91
Да об обычный if (a=b) вместо if (a==b) сколько копий сломано, что уж говорить о чем-то более сложном.
if (...);
{
// do smth
}
Недавно я написал статью "Статья о статическом анализе кода для менеджеров, которую не стоит читать программистам". Вполне закономерно к ней начали оставлять комментарии о том, что нет пользы от инструмента поиска простых ошибок. Приведу один из таких комментариев:
Не совсем понятно, к чему популизировать миф, как будто все программисты против статического анализа или ненавидят его?
Человек написал, что он один раз попробовал один из них, убил впустую три дня. Окей, из-за этого он убедился, что они ему не нужны. Ну может быть.
А причем тут остальные программисты и "закономерно"?
Причем, как уже вам написали, в 99% случаев причиной для того, что бы не использовать инструменты статического анализа является менеджер — "нет денег", "это все глупость", "вот выкатим релиз/второй релиз/… и займемся анализом" и так далее.
Практически на каждую технологию есть кто-то, кто скажет "не нужно", потому что у него был другой случай, когда статический анализ не помог и не мог помочь.
Аналогичная ситуация с юнит-тестами, ООП, паттернами и розовыми поняшками. Мне кажется странным делать из этого причину для отдельной статьи.
К тому же, учитывая что, что большинство людей в целом вас поддержало.
Не совсем понятно, к чему популизировать миф, как будто все программисты против статического анализа или ненавидят его?Так маркетинг. Вы посмотрите контекст последних статей.
«Наш анализатор необходим каждому, а программисты возражают против него просто из вредности, боязни и т.д… Купи анализатор, докажи что ты круче программиста, поставь засранца на место»:)
Не уверен, что это работает.
Вроде как большинство менеджеров, которым такое нужно и так кажется, что они круче программистов.
Купи анализатор, докажи что ты круче программиста, поставь засранца на место»
Кстати, в этом что-то есть. Я не призываю так поступать, однако иногда умелое использование такой методики пожалуй может дать воспитательный эффект. :)
Проблема в том, что:
- индюки и без того в этом уверены,
- большая часть из тех, кто всё-же захочет опустить (к счастью таких не очень много) будет пытаться добиться инфы "а как опустить", потому что сам с инструментом не справится
- остальные деляется на четыре подкатегории
а программисты им уже устали объяснять, как полезен стат. анализ
б у проекта нет средств
в они уже купили инструмент стат.анализа
г программисты продавили использования опен-сорсных решений стат. анализа (это больше касается java, возможно в каких-то ещё экосистемах есть качественные оперсорсные решения стат.анализа).
Т.е. вы изначально не с той категорией работаете. Вам ведь нужны категории 3а и 3б, возможно попытаться зацепить 3в и 3г. А для них нужен другой материал — в чём будет заключаться выгода на их языке. А это экономический язык… чего я у вас ни разу не видел.
Например
Сейчас мне интереснее обсудить вот какую тему: многие программисты считают, что по-настоящему серьезные ошибки можно допустить только при реализации алгоритмов
В аналогичном ключе была написана и оригинальная статья.
Из-за нее складывается впечетление, что большинство профессиональных и опытных программистов считают, что статический анализатор не нужен, но это далеко не так.
В комментариях большинство в целом согласились со статьей, но на основе комментариев одного человека, была написана еще одна статья, которая опять получилась в духе "программисты не понимаю, что статический анализ нужен".
Где все эти программисты?
Возможно, я предвзят, но у меня сложилось впечетление, что это определенно попытка популяризации какого-то странного мифа про программистов.
Где все эти программисты? Возможно, я предвзят, но у меня сложилось впечатление, что это определенно попытка популяризации какого-то странного мифа про программистов.К сожалению, их много. Если у вас есть пара недель свободного времени предлагаю прочитать все комментарии, ко всем нашим статьям в блоге. Вы увидите, что я пишу это от того, что «наболело».
Я просмотрел нестолько статей и, честно говоря, не особо увидел, кучи людей, которые бы в каждой статье писали, что "статические анализаторы не нужны".
С тем, что они не нужны в их случае, потому что у них и кода мало, и проект не такой прибыльный и прочее сложно не согласится.
Или я не прав, и находятся люди, которые утверждают, что статический анализ бесполезен для любых проектов?)
Как и людей, любящих интерполировать исключительно свой опыт на всю отрасль
Вы делаете абсолютно так же, когда утверждаете, что "статический анализ в каждый проект". Большинство проектов — это мелкие или средней сложности сайты, для которых внедрение с статического анализа и его поддержка банально не окупится.
Многие — это должно быть достаточно весомое количество. Я понимаю, когда говорят, что многие программисты выступают против TTD, я вижу, их мнение доходит до Хабра, например.
А кто те многие, которые выступают против статического анализа?
Загуглив "статический анализ не работает" я не могу найти статьи, которые бы говорили против него, найти такое же для TDD не составит труда.
Так кто эти "многие"?
А кто те многие, которые выступают против статического анализа?Я видел их в комментария, в почте. Но я никогда не собирал ссылки на такие дискуссии, поэтому не могу сейчас достать список «100 примеров». В общем с пруфами затруднение и даже как поискать не знаю. С ходу только вспомнилась заметка "Народ против PVS-Studio: дубль первый" с выводом в конце: не следует полагаться на анализаторы, скорее нужно просто повысить свой уровень профессионализма. Формально вывод правильный, но при разборе статьи выясняется, что автор просто не разобрался в вопросе.
Возможно, я не прав, но учитывая, что автор проводил сравнение инструментов синтаксического анализа, то вряд ли он выступал против использования таких инструментов.
На мой взгляд, выступать против можно так: Исследование, в котором говорится, что TDD не работает
А так, как никто не ожидает от статического анализа серебрянной пули и того, что он решит все проблемы, то и выступать против него никто не собирается. Ну, или мне так кажется.
К сожалению часты ложные срабатывания.
Проблема использования статических анализаторов одна — деньги:
Менеджеры не дают денег, а компании разрабатывающие такие продукты хотят очень много денег (от части обоснованно, т.к. алгоритмы довольно сложные, а задача нетривиальная).
Вообще статический анализ должен стать частью IDE — может быть когда-нибудь увижу его в Visual Studio.
По поводу приведённых примеров — это скорее всего результат работы неопытных разработчиков, т.к. большинство опытных знают, что if лучше не использовать без { }. А все остальные примеры актуальны только для C++, т.к. в Java или C# либо компилятор не позволит такое сделать, либо просто нет необходимости манипуляции на уровне байтов.
Вообще статический анализ должен стать частью IDE — может быть когда-нибудь увижу его в Visual Studio.
PVS-Studio есть для Visual Studio (скрины), так же там есть стандартные простые статические анализаторы для C++ и C#, или что вы имели ввиду?
- Сравнение анализаторов кода: CppCat, Cppcheck, PVS-Studio, Visual Studio
- Как мы сравнивали анализаторы кода CppCat, Cppcheck, PVS-Studio, Visual Studio
Понимаю, вам кажется, что это случайность. Ну а мне — что закономерность. Проявление правила про 20% людей, выпивающих 80% пива. Иными словами, разработчики компилятора включают в него лишь самые полезные варианты статанализа.
Подумайте о том, что у сырого кода плотность ошибок может достигать 100 на 1000 строк. А когда вы тестируете открытые проекты — плотность сильно меньше. И достигается это как раз компилятором.
Сделайте тест на своем проекте. Напишите тысячу строк кода без компиляции. И посмотрите число ошибок, которые даст компилятор при -Wall -Wextra и PVS-Studio.
Причина простая: основные баги — в алгоритмах. В работе аналитиков, математиков, постановщиков, алгоритмистов. А багов при кодировании — не так много.
Вы уводите дискуссию в другой русло. Jef239 весь исходный пост пытался добиться ответа на вопрос: при каких условиях внедрение PVS-Studio окупится? Единственная внятная метрика, которую вы указали: размер проекта, минимум (условный) 250,000 Lines of Code.
Судя по текущей статье, добавляется еще одна метрика: проект должен быть уровня iOS или MySQL (подозреваю, в такого роде проектах уже есть 250k LoC).
Вы можете предложить еще какие-то параметры оценки окупаемости PVS-Studio?
- Когда статический анализ начинает оправдывать время, затраченное на разбор его предупреждений?
- Когда PBS-Studio начинает оправдывать свою цену?
- Когда покупка PVS-Studio становится выгоднее иных мер?
- Когда багфиксинг становится выгоднее развития проекта? То есть появляется смысл сокращать технический долг, а не накапливать его?
- Когда поиск потенциальных ошибок важнее исправления реально проявляющихся ошибок?
На первый вопрос есть ответ про 250КLoc.
На второй — есть гипотеза, что это происходит когда ФОП за 1 день в месяц всех девелоперов (12 дней в год) становится больше цены PVS-Studio. Видимо это означает от пары сотен разработчиков.
На третий скорее всего ответ — когда матстимулирование уже не помогает. То есть зарплаты разработчиков настолько превышают среднюю оплату, что премии уже не дают отдачи. Впрочем, могу быть неправ. Кроме того, есть условно-бесплатные техники вроде TDD.
На четвертый — скорее всего тогда, когда маркетологи с трудом придумывают, а что бы ещё включить в новую версию. Ибо вся основная функциональность уже есть. а то, что просят — нужно лишь единицам пользователей.
На пятый — видимо речь о специальных областях с большими рисками. АСУТП, банковские приложения, космос и так далее — везде, где можно потерять миллионы долларов. Разумный критерий — если цена скрытой ошибки больше, чем в сто раз превышает стоимость статанализатора — его есть смысл применять.
А на то, что вы написали — отвечу чуть позже.
Перед вами стоит задача купить 10 компьютеров для нового отдела программистов. Вы не будете делать никакой расчет по оценки окупаемости. Вот как оценить нужно купить мышку за 300 или 400 рублей? Первая дешевле, но вторая надежнее. Как выбрать? Проводить опрос у программистов, читать обзоры? А монитор — 22 или 25 дюймов? Что лучше? Первый дешевле, а второй показывает больше кода и программисты возможно будут работать быстрее. Как посчитать окупаемость для монитора? А стоит экономить на памяти или нет? А наушники нужны для большего комфорта или обойдутся без них?
В итоге вы будете действовать на глазок. Вы просто понимаете, нужен компьютер вот с такой конфигурацией или нет. А от меня хотят услышать такой же сложный расчёт для анализатора. Ведь в нем как и с компьютером много субъективного. Кто может посчитать на сколько процентов увеличивают эффективность работы мониторы разного размера?
Так как же тогда выбирают компьютеры для команды программистов? По ощущению. Вот тоже самое получается и со статическим анализом. Он или нужен или нет. Или чувствуется потребность или нет. Ибо что с компьютерами, что со статическим анализатором траты на зарплаты не соизмеримо больше.
А от вас я жду не расчета, а оценки. Если вы не имеете такой оценки — значит вы не имеете образа покупателя и не понимаете, кто ваш клиент, а кто нет.
Отсюда — и те заявления, что меня раздражают своей всеобщностью.
А заказчику перед покупкой все равно приходится такой анализ сделать. Если покупка компа в любом случае выгодна и речь идет о процентах, то станализатор вполне может не окупиться. Ну например в моем случае (до 50КLoc в основном проекте) — килобаксы за PVS-studio не окупятся.
Опять мы встречаемся с мифом, что профессиональные разработчики не допускают простых ошибок.
Допускают. Ещё как допускают — компилятор каждый день мне говорит об этом. Но:
- Ошибки бывают как в кодировании, так и в алгоритмах, матметодах, менеджменте (я про мисфичи)
- Большую часть ошибок кодирования находит компилятор.
- Статанализатор находится лишь часть ошибок, оставшихся после компияции.
Пример из РД 50-25645.325-89:
Запятую вместо точки в коде мне найдет компилятор. А кто найдет + вместо — (реальная ошибка в ИКД ГЛОНАС)? А если 1 вместо 7?
А вот любимый пример мисфичи. Несмотря на максимально жесткое тестирование авионики просто забыли включить функциональность в результирующий проект. Примерно аналогичная ошибка похоронила 3 спутника ГЛОНАСС. Там изменили размеры бака, но ни расчетчики, ни QA этого не поняли.
Ну а вот и ваша статья о менеджерских ошибках в развитии проекта PVS-Studio. Ошибки дорогостоящие. но статический анализ их никак не ловит.
В итоге получается примерно так. 40% ошибок — это кодирование. Из них 70% ошибок (28% всех ошибок) находит компилятор. Из оставшихся 12% ошибок статанализ находит 3-5%. То есть — 0.4-0.6% общего числа ошибок находятся статаналиом.
Понятно, что цифры — условные, жду от вас вашей собственной оценки.
Ну и о ваших примерах. goto fail вне if — ну так dead code находится компилятором. Это как раз та часть статанализа, которую компиляторы обычно умеют. Неявное приведение типа с обрезанием значимой части — опять диагностируется компиляторами. Третий пример — целочисленное переполнение. И опять — зачастую компиляторы это умеют, правда не статически, а динамически.
В итоге получается, что рекламируя платный продукт вы на самом деле рекламируете возможности компиляторов. Причем зачастую — бесплатных компиляторов.
Ну а о том, что компилировать надо с -Wall -Wextra — никто не спорит.
Если бы это было не так, не было этой базы с 11000 ошибками.
И именно поэтому статические анализаторы такие как PVS-Studio или Coverity были, есть и будут. Они всегда идут на шаг или два впереди компиляторов в плане диагностик.
Увлекаясь критикой стат. анализторов, Вы начинаете приписывать компиляторам магические возможности, которых нет. Например, так дело обстоит с целочисленным переполнением. Эта и подобные ошибки положили начало созданию Viva64, который со временем превратился в PVS-Studio. И искать подобные ошибки компиляторы не умели, не умеют и не собираются учиться. Что-бы не быть голословным, буквально на днях у нас появился новый клиент, купивший лицензию на PVS-Studio ради 64-битных диагностик. Именно ради них! Видимо пришло делать 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 хочется попробовать. Если скажите, где найди виндовую сборку — буду рад. СУдя по вашей же статье — он похож на лучший из бесплатный.
-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);
Предлагаем заключить маленький контракт, в рамках которого мы исследуем проект и исправим все ошибки, которые сможем найти. Во-первых, это в любом случае будет полезно, а во-вторых, если результат вам понравится, это откроет путь для дальнейшего сотрудничества. В случае необходимости мы готовы подписать NDA. Предлагаю обсудить детали по почте.
А вот это стоит отдельной статьи. Ибо мнения о том, что статанализ есть смысл предоставлять как сервис — я читаю уже 3-4 года в комментариях к вашим статьям.
Вопрос, как обычно в цене. Сколько будет стоит получение полного лога без исправления ошибок? Сколько будет стоить ручная фильтрация ложных предупреждений? Про исправление не спрашиваю — исправление, сделанное без понимания проекта все равно полетит в мусорную корзину.
P.S. При разумных ценах — прогнозирую бешеный успех.
Польза для производителя тоже понятна — это подкормка рыбы перед подсчечкой. Во время SaaS выясняются финансовые возможности клиента и особенности его софта.
А вот какую модель ценообразования они выберут… Письмо я написал, в ответ «да и нет не говорите, черное и белое не называйте». О цене — молчат как партизаны на допросе. Будем считать это вежливым отказом в обслуживании.
Для SaaS ценообразование понятное — в основе экономия времени клиента на установку бесплатной версии. То есть несколько дней ФОП девелопера. Дальше это все множится на жадность производителя (с учетом выгоды от обнаружения ошибок).
Интересный финт ушами будет, если цена будет зависеть от количества обнаруженных ошибок по сравнению с прогнозом. Программеры все оптимисты, так что на этом можно заработать.
Вряд ли взлетит. Все-таки стат анализ нужен не разово, а постоянно.Мы думаем, такие проверки могут быть хорошим способом познакомиться и продемонстрировать возможности PVS-Studio. А даже если дальнейшее сотрудничество не сложится, в программе станет меньше багов, что тоже хорошо.
ИМХО нужно популяризировать статический анализ, в том числе и как SaaS, и сделать его доступным, скажем, инди-студиям за пару тыщщ деревянных за запуск. Они будут пользоваться им раз в полгода, найдя все опечатки, потом подсядут, а то и лучше кодить начнут — особенно если из-за какого-нибудь интересного бага, который не вылавливается силами программистов по какой-либо причине, но ловится стат.анализатором, придется его запустить, после чего какой-нибудь git blame покажет, кто сделал этот баг, и с него полетят денежки. Денежный стимул — самый серьезный в современном мире "волшебный пендаль". Если вы сможете (вопрос, к сожалению, сложный — для проверки проекта потребуется реально развернуть весь проект со всеми сторонними библиотеками, если я правильно понимаю механизм работы PVS-Studio) предоставить статический анализ как услугу, мне кажется, она будет востребована довольно большим числом людей, чтобы появилась достаточная для окупаемости конверсия.
На днях ради интереса скачал и запустил ваш плагин на одном своем проекте, но на любые попытки анализа PVS ругается, что это не C++ или C# проект. Такое впечатление, что он не видит стандартного файла проекта и больше ничего делать не хочет.
P.S. В поддержку писать не стал, т.к. интерес чисто академический.
PVS-Studio соткан из противоречий.
Рекламирует себя как B2B но почему-то в виде массового спама статьями на хабре.
Уступает Coverity по глубине анализа, а решарперу по всем прочим пользовательским характеристикам сразу.
Как результат — ниша очень дорогого дополнения к имеющемуся инструментарию, чья единственная ценность в правилах, которые не покрывает решарпер.
Прибыльность такого бизнеса столь же загадочна как и цена продукта.
Внезапно, да:
http://jetbrains.ru/products/resharper-c/
решарперНе стоит смешивать статические анализаторы кода и productivity tools. Статический анализ это подробная документация по всем диагностикам, поддержка и консультирование, это интеграция с IncrediBuild, это Standalone, это инструменты интеграции в большой проект (например, база разметки сообщений), отслеживание запусков компилятора (CLMonitoring), рассылка писем и т.д.
Не стоит дезинформировать читателей:
Статический анализ кода это процесс выявления ошибок и недочетов в исходном коде программ. Статический анализ можно рассматривать как автоматизированный процесс обзора кода.
Я надеюсь, вы знаете, откуда эта конкретная цитата. Этому определению решарпер полностью удовлетворяет.
Википедия:
Стати́ческий ана́лиз ко́да (англ. static code analysis) — анализ программного обеспечения, производимый (в отличие от динамического анализа) без реального выполнения исследуемых программ
И этому определению решарпер полностью удовлетворяет.
Сайт JetBrains:
Статический анализ качества кода и автоматическое исправление обнаруженных проблем
Для всех поддерживаемых языков ReSharper распознает ошибки компиляции, времени выполнения и логические ошибки, а также избыточные и неоптимальные конструкции, и подсвечивает обнаруженные проблемы прямо в редакторе. Более тысячи инспекций, которые ReSharper использует для поиска проблем в коде, позволят мгновенно увидеть все потенциально опасные места в текущем файле или даже во всем решении Visual Studio. Для большинства из них ReSharper предложит один или более вариантов автоматического исправления.
Даже если вы сами избегаете сравнения с решарпером любой ценой, потенциальные клиенты все равно будут это делать.
Причем никакие ваши плюшки не побьют решарперовскую обратную связь в реальном времени, если только ваше средство не будет обнаруживать дефекты, которые решарпер не находит.
Вы можете дать такие примеры?
Что касается C++ то, я заявляю, что PVS-Studio лучше многих анализаторов кода (ReSharper, Cppcheck, ...). Наступаем на пятки и в ближайшее время превзойдём по многим направлениям Coverity и Klocwork. Я знаю, что PVS-Studio крут и мы регулярно это показываем на практике. Если кто-то хочет опровергнуть, пусть попробует доказать обратное.
Использование ReSharper не мешает находить нам ошибки в C# проектах.
Andrey2008 вы гарантируете, что использование PVS-Studio позволит забыть о диагностиках выдаваемых R#?
@Andrey2008 этого и не утверждал.
Со своей стороны могу точно сказать, что статическим анализом решарпера пренебрегать нельзя. Например, несколько классов с дефектами из статьи по ссылке он справедливо предлагает выкинуть как неиспользуемые.
Ну и результаты выдает в реальном времени прямо в студии
Но вы же понимаете, что у анализаторов такие же гарантии, как и у компаний, выдающих самые крутые сертификаты безопасности. От продуктов есть выгода и польза, но никто не требует невозможного.
И R# не статический анализатор, а большая большая надстройка с горой функционала, среди которого анализ кода далеко не основная задача, а совсем малая часть. И вообще Вы можете найти много негативных отзывов о производительности R# при разработке, и сами разработчики это знают, поэтому ограничены в возможностях. PVS-Studio же занимается только статическим анализом, что за тоже самое время позволяет получить совсем другое качество анализа.
И R# не статический анализатор
Да неужели?
Решарпер умеет много чего еще, но собственно статическим анализом (по определению с вашего же сайта!) занимается в первую очередь.
Почему вы отрицаете очевидное?
И вообще Вы можете найти много негативных отзывов о производительности R# при разработке, и сами разработчики это знают, поэтому ограничены в возможностях.
У решарпера имеются проблемы с производительностью на больших проектах в реальном времени. Насколько мне известно PVS Studio в таком режиме вообще не работает.
PVS-Studio же занимается только статическим анализом, что за тоже самое время позволяет получить совсем другое качество анализа.
Время на что именно сравнивалось и где?
И R# не статический анализатор
Да неужели?
Именно так, статический анализ одна из возможностей, как и у компилятора.
ReSharper (R#) — дополнение (плагин), разработанное компанией JetBrains для повышения продуктивности работы в Microsoft Visual Studio.
ReSharper повышает эффективность разработки в Microsoft Visual Studio и помогает автоматизировать большинство рутинных процедур.
А теперь представьте, если всё это выкинуть и заняться только глубоким статическим анализом, будет совсем другой эффект.
Именно так, статический анализ одна из возможностей, как и у компилятора.
С точностью до наоборот. Вы почему-то трактуете включение как исключение.
А между тем и компиляторы, и решарпер являются статическими анализаторами и более того, активно используются в этом качестве.
И без сравнения с ними никакому иному статическому анализатору (PVS Studio) не обойтись.
А теперь представьте, если всё это выкинуть и заняться только глубоким статическим анализом, будет совсем другой эффект.
Мне не нужно ничего представлять, мне нужен конкретный результат. Если вы заявляете что PVS Studio быстрее решарпера, то покажите где и насколько (этого я не видел). Если заявляете что анализирует глубже — покажите случаи, когда PVS Studio находит ошибки, которые не по зубам решарперу (это я сделал за вас).
Ответы "X (делающий статический анализ) не статический анализатор" для вашего продукта скорее вредны чем бесполезны.
PVS-studio скорее всего оправдает потраченное на разбор время, но не оправдает те килобаксы, за которые он продается.
А пиратить продукт российских коллег просто не хочется.
Использование ReSharper не мешает находить нам ошибки в C# проектах.
Очень хорошая иллюстрация к вашим тезисам.
Я чисто для проформы скачал этот проект себе и проверил решарпером.
Результаты (сравнение про найденным дефектам из вашей статьи):
- Ошибку с безусловной рекурсией и переполнением стека решарпер успешно находит.
- Ошибку с TimeSpan.Seconds решарпер не нашел.
- Пропущенное значение в switch решапер нашел.
- Отсутствие использования значения чистой функции Except решарпер нашел.
Про отрицательное значение в методе Substring у вас ложное срабатывание во всех трех случаях, причем для понимания этого факта в первом случае достаточно посмотреть на строку выше от цитаты.
if (!identityEntry.StartsWith("/")) return null; var indexOfEquals = identityEntry.IndexOf("="); if (indexOfEquals < 0) return null; var key = identityEntry.Substring(1, indexOfEquals - 1);
После первой строки в IdentityString первый символ всегда слеш по построению и IndexOfEquals никогда не будет равен нулю.Остальные два случая полностью аналогичны.
- Для операции ?? решарпер точно так же определяет что первый аргумент не может оказаться null
- Всегда ложное значение условия в if решарпер пропустил.
- Возможность словить NRE в данном случае решарпер пропустил.
Итоги:
- Решарпер для статического анализа кода в Orchard или не используется вообще или это делается заведомо неправильно.
- PVS Studio находит реально опасные дефекты, которые не обнаруживает решарпер.
- Польза от использования конкретно PVS Studio есть, но авторы инструмента допускают наличие дезинформации (уверен, что непреднамеренной) в своих материалах.
- Решарпер может и должен использоваться в том числе как статический анализатор кода.
Пропустил статью :-) Мне регулярным евангелизмом статического анализа лень заниматься, так что дарю вам ещё довод, раз уж вы занимаетесь. Ошибку вам может внести сама 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 и не обратить внимания на то, что она сделала, можно здорово обжечься. Я недавно написал диагностику, которая отлавливает статически такой код. В нашем проекте нашлось несколько мест, где он появился именно в результате применения рефакторинга.
Правильно, я тоже предлагаю. Надо просто понимать, что автоматический исправлятор тоже может накосячить. Голову отключать никогда не надо и весь свой код перечитывать перед коммитом обязательно. Ну и статический анализ использовать — он заметит то, чего вы не заметите :-)
Вот, кстати, похожий конкретный пример из реального кода. Было:
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. Думаю, если б человек вручную переменную создал, он бы заметил проблему.
Думаю, если б человек вручную переменную создал, он бы заметил проблему.
Наблюдал кучу различных ошибок копи-пасты и прочих рефакторингов. И вот знаете, что-то сомнения берут, что человек обязательно бы заметил проблему… С вероятностью эдак 80-90% пропустил бы, имхо.
В таких случаях проверку на длину лучше вынести отдельно, примерно так:
if (elements.length == 0)
return;И для остальных проверок границ поступать аналогично. Такой код и читается проще и авторефакторинги с ним лучше дружат.
Обычно да, но конкретно тут не подойдёт: нужно ещё выполнить некоторый код безусловно после проверки. В принципе это всё сигнализирует, что хорошо бы весь метод порефакторить и разбить на более мелкие, но в реальной жизни не бывает так, что весь код выглядит идеально.
В принципе это всё сигнализирует, что хорошо бы весь метод порефакторить и разбить на более мелкие, но в реальной жизни не бывает так, что весь код выглядит идеально.
Выделение метода делается в три клика: такие рефакторинги из области чистки зубов и их цена однозначно перекрывается улучшением читаемости кода. Тут лучше не лениться, а следовать правилу бойскаута.
Это если возвращаемое значение в блоке кода одно и нет нелокального control flow. А если нет? Extract method object обычно генерирует результат далёкий от оптимального. И даже если и с возвращаемым значением всё нормально, сигнатура результирующего метода может оказаться перегруженной и запутанной. Чтобы сделать всё красиво, зачастую всё равно думать приходится. Да и не весь код в мире написан в те годы, когда в IDE Extract method уже хорошо работал.
Это если возвращаемое значение в блоке кода одно и нет нелокального control flow.
Тогда тем более надо рефакторить — это говорит о совсем нехорошем запахе в коде.
Я не к тому, что надо кидаться менять все и вся, но уж если нужны правки, то они должны вноситься после рефакторинга, делающего код в месте исправления очевидным.
И попытка авторефакторинга, после которой генерируется ужас — детектор подгнившего кода, иногда позволяющий демаскировать ранее незаметные для человека проблемы.
Автоматические рефакторинги ни в коем случае не отменяют необходимость думать, а напротив, позволяют быстро направить мысли в правильное русло.
Простая ошибка при кодировании — не значит нестрашная ошибка