Наш менеджмент недавно говорил с некоторыми людьми, продающими инструменты статического анализа С++ . Конечно, продавцы говорят, что найдут множество ошибок, но я скептически отношусь.
Как эти инструменты работают в реальном мире? Находят ли они настоящие ошибки? Помогают ли они более молодым программистам учиться?
Неужели они стоят проблемы?
Анализ статического кода почти всегда стоит того. Проблема с существующей базой кода заключается в том, что она, вероятно, сообщит слишком много ошибок, чтобы сделать ее полезной из коробки.
Я когда-то работал над проектом, в котором было 100 000+ предупреждений от компилятора... нет смысла запускать инструменты Lint на этой базе кода.
Использование инструментов Lint "правильно" означает покупку лучшего процесса (что хорошо). Одна из лучших работ, которые у меня были, работала в исследовательской лаборатории, где нам не разрешалось проверять код с предупреждениями.
Итак, да, инструменты стоят того... в долгосрочной перспективе. В краткосрочной перспективе включите предупреждения своего компилятора до максимума и посмотрите, что он сообщает. Если код "чистый", тогда время, чтобы посмотреть инструменты линта, теперь. Если код содержит много предупреждений... расставьте приоритеты и исправьте их. Как только код не имеет предупреждений (или, по крайней мере, очень мало), посмотрите на инструменты Lint.
Итак, инструменты Lint не помогут плохой базе кода, но как только у вас будет хорошая база кода, это может помочь вам сохранить ее.
Изменить:
В случае продукта с 100 000 + предупреждения он был разбит на 60 проектов Visual Studio. Поскольку каждый проект удалял все предупреждения, он был изменен, чтобы предупреждения были ошибками, что предотвращало добавление новых предупреждений в проекты, которые были очищены (точнее, это позволяло моему коллеге праведно кричать на любого разработчика, который проверял в код без его компиляции сначала:-)
По моему опыту с несколькими работодателями, Coverity Prevent for C/С++ явно стоило того, чтобы найти некоторые ошибки даже в хорошем коде разработчиков и множество ошибок в худшем коде разработчиков. Другие уже затронули технические аспекты, поэтому я сосредоточен на политических трудностях.
Во-первых, разработчики, чей код нуждается в статическом анализе больше всего, наименее вероятно используют его добровольно. Поэтому я боюсь, что вам нужна сильная поддержка управления, как на практике, так и в теории; в противном случае он может оказаться как элемент контрольного списка, чтобы получить впечатляющие показатели без фактического исправления ошибок. Любой инструмент статического анализа будет создавать ложные срабатывания; вам, вероятно, понадобится посвятить кого-то, чтобы свести к минимуму раздражение от них, например, путем устранения дефектов, определения приоритетов шашек и настройки настроек. (Коммерческий инструмент должен быть очень хорош в том, что он никогда не демонстрирует ложных срабатываний более одного раза, это само по себе может стоить того.) Даже настоящие дефекты, вероятно, вызовут раздражение; мой совет по этому поводу - это не беспокоиться о том, что, например, комментарии в комментариях ворчат, что явно разрушительные ошибки являются "незначительными".
Мой самый большой совет - это следствие моего первого закона, выше: сначала возьмите дешевые снимки и посмотрите на мучительно очевидные ошибки от ваших худших разработчиков. Некоторые из них, возможно, даже были обнаружены предупреждениями компилятора, но многие ошибки могут проскальзывать через эти трещины, например, когда theyre подавляется параметрами командной строки. На самом деле вопиющие ошибки могут быть политически полезными, например, с Десятым списком самых смешных дефектов, которые прекрасно могут сосредоточить ум, если их использовать осторожно.
Это помогает. Я бы предложил взять пробную версию и запустить ее через часть вашей кодовой базы, которая, по вашему мнению, игнорируется. Эти инструменты генерируют много ложных срабатываний. Как только вы пробрались через них, вы, вероятно, найдете переполнение буфера или два, которые могут сэкономить много горя в ближайшем будущем. Кроме того, попробуйте по крайней мере две/три разновидности (а также некоторые из материалов OpenSource).
Как заметили пара людей, если вы запускаете инструмент статического анализа в большинстве приложений, вы получите много предупреждений, некоторые из них могут быть ложными срабатываниями или могут не привести к эксплуатационному дефекту. Именно этот опыт приводит к восприятию того, что эти типы инструментов являются шумными и, возможно, пустая трата времени. Однако есть предупреждения, которые будут выявлять реальные и потенциально опасные дефекты, которые могут привести к проблемам безопасности, надежности или корректности, а также для многих команд, эти проблемы важны для исправления и могут быть почти невозможны для обнаружения через тестирование.
Тем не менее, инструменты статического анализа могут быть очень полезными, но применение их к существующей кодовой базе требует небольшой стратегии. Вот несколько советов, которые могут вам помочь.
1) Не включайте все сразу, выбирайте начальный набор дефектов, включайте эти анализы и фиксируйте их по всей базе кода.
2) Когда вы обращаетесь к классу дефектов, помогите всей команде разработчиков понять, что такое дефект, почему это важно и как кодировать для защиты от этого дефекта.
3) Работать, чтобы полностью очистить кодовую базу от этого класса дефектов.
4) Как только этот класс проблем был исправлен, введите механизм, чтобы оставаться в состоянии нулевой проблемы. К счастью, гораздо проще убедиться, что вы не повторно вводите ошибку, если у вас есть базовый уровень, не имеет ошибок.
Я использовал их - например, PC-Lint, и они нашли кое-что. Как правило, они настраиваются, и вы можете сказать им, что "перестаньте беспокоиться обо мне о xyz", если вы определите, что xyz действительно не проблема.
Я не знаю, что они помогают младшим программистам многому научиться, но их можно использовать как механизм, чтобы помочь подтянуть код.
Я обнаружил, что второй набор (скептический, зондирующий для ошибок) глаз и модульное тестирование, как правило, там, где я видел больше ловушек ошибок, имеют место.
Эти инструменты помогают. lint был отличным инструментом для разработчиков C.
Но одно возражение, которое у меня есть, это то, что они - пакетные процессы, которые запускаются после того, как вы написали достаточное количество кода и потенциально генерируете много сообщений.
Я думаю, что лучший подход заключается в том, чтобы создать такую вещь в вашей среде IDE и указать на проблему, пока вы ее пишете, чтобы сразу ее исправить. Не позволяйте этим проблемам попасть в базу кода в первую очередь.
Это разница между инструментом статического анализа FindBugs для Java и IntelliJ Inspector. Я очень предпочитаю последнее.
Вам, вероятно, придется иметь дело с хорошим количеством ложных срабатываний, особенно если ваша база кода большая.
Большинство инструментов статического анализа работают с использованием "внутрипроцедурного анализа", что означает, что они рассматривают каждую процедуру изолированно, в отличие от "цельнопрограммного анализа", который рассматривает всю программу.
Обычно они используют "внутрипроцедурный" анализ, потому что "анализ всей программы" должен учитывать многие пути через программу, которая на самом деле никогда не будет на практике, и поэтому может часто генерировать ложноположительные результаты.
Внутрипроцессный анализ устраняет эти проблемы, просто сосредоточив внимание на одной процедуре. Однако для работы обычно требуется ввести "язык аннотации", который вы используете для описания метаданных для аргументов процедуры, типов возвращаемых данных и полей объектов. Для С++ эти вещи обычно реализуются с помощью макросов, которые вы украшаете. Затем аннотации описывают такие вещи, как "это поле никогда не является нулевым", "этот строковый буфер защищен этим целочисленным значением", "к этому полю может быть обращено только поток, помеченный как" фон "и т.д.
Инструмент анализа затем примет аннотации, которые вы предоставите, и убедитесь, что написанный вами код на самом деле соответствует аннотации. Например, если вы могли бы передать значение null на то, что помечено как не пустое, оно будет отмечать ошибку.
В отсутствие аннотаций инструмент должен принять худшее, и поэтому будет сообщать много ошибок, которые на самом деле не являются ошибками.
Поскольку, похоже, вы уже не используете такой инструмент, вы должны предположить, что вам придется потратить значительное количество времени на аннотирование кода, чтобы избавиться от всех ложных срабатываний, которые изначально будут сообщены. Сначала я запускаю инструмент и подсчитываю количество ошибок. Это должно дать вам оценку того, сколько времени вам потребуется, чтобы принять его в базе кода.
Ветерок или нет, этот инструмент стоит того, что зависит от вашей организации. Каковы типы ошибок, которые вам больше всего нравятся? Будут ли они перегружать ошибки? Являются ли они ошибками, вызванными нулевыми ошибками или ошибками памяти? Являются ли они проблематичными? Являются ли они "упущенными, что мы не рассматривали этот сценарий", или "мы не тестировали китайскую версию нашего продукта на литовской версии Windows 98?".
Как только вы выясните, в чем суть проблемы, вы должны знать, стоит ли это делать.
Инструмент, вероятно, поможет с ошибками переполнения буфера, нулевой разыгрывания и ошибок утечки памяти. Там есть вероятность, что он может помочь с ошибками в потоковой передаче, если он поддерживает анализ "раскраски нитей", "эффектов" или "разрешений". Тем не менее, эти типы анализа довольно передовые и имеют ОГРОМНОЕ нотационное бремя, поэтому они действительно приносят с собой некоторые расходы. Инструмент, вероятно, не поможет с другими типами ошибок.
Итак, это действительно зависит от того, какое программное обеспечение вы пишете, и какие ошибки вы используете чаще всего.
Я думаю, что статический анализ кода стоит того, если вы используете правильный инструмент. Недавно мы попробовали инструмент Coverity Tool (немного дорогой). Его удивительный, он выявил множество критических дефектов, которые не были обнаружены линией или очистились.
Также мы обнаружили, что мы могли бы избежать 35% дефектов поля клиента, если раньше мы использовали покрытие.
Теперь Coverity выставляется в моей компании, и когда мы когда-либо получаем клиентскую версию TR в старой версии программного обеспечения, мы используем ее, чтобы выявить возможные недостатки по вине, прежде чем мы начнем анализ в susbsytem.
Плата за большинство инструментов статического анализа, вероятно, не нужна, когда есть некоторые очень качественные бесплатные (если вам не нужна особая или специфическая функция, предоставляемая коммерческой версией). Например, см. Этот ответ, который я дал по другому вопросу о cppcheck.
Я думаю, это зависит от вашего стиля программирования. Если вы в основном пишете C-код (со случайной функцией С++), то эти инструменты, вероятно, смогут помочь (например, управление памятью, переполнение буфера,...). Но если вы используете более сложные функции С++, тогда инструменты могут запутаться при попытке проанализировать исходный код (или просто не найдете много проблем, потому что средства на С++ обычно безопаснее использовать).
Как и во всем, ответ зависит... если вы единственный разработчик, работающий над принцессой вязания-шаблона для вас, бабушка, вы, вероятно, не захотите покупать какие-либо инструменты для статического анализа. Если у вас проект среднего размера для программного обеспечения, который войдет во что-то важное, и, возможно, помимо того, что у вас ограниченный график, вы можете немного инвестировать сейчас, что значительно сэкономит вам больше времени.
Недавно я написал общий текст: http://www.redlizards.com/blog/?p=29
Я должен написать часть 2, как только позволит время, но в целом сделать некоторые грубые вычисления, стоит ли это для вас:
Мое личное дело также:
получить статический анализ в раннем
предоставить разработчику возможность самостоятельно использовать статический анализ
Этот довольно удивительный результат был выполнен с использованием Эльзы и Оинка.
http://www.cs.berkeley.edu/~daw/papers/fmtstr-plas07.pdf
"Масштабный анализ уязвимостей форматирования в Debian Linux" Карл Чен, Дэвид Вагнер, UC Berkeley, {quarl, daw} @cs.berkeley.edu
Аннотация:
Ошибки в формате строки являются относительно общей уязвимостью системы безопасности и могут привести к произвольному выполнению кода. В сотрудничестве с другими нами мы разработали и внедрили систему для устранения уязвимостей строки формата из всего дистрибутива Linux, используя вывод типаquali fier, метод статического анализа, который может обнаруживать нарушения в нарушении. Мы успешно анализируем 66% исходных пакетов C/С++ в дистрибутиве Debian 3.1 Linux. Наша система содержит предупреждения об ограничении строки в 1533 формате. По нашим оценкам, 85% из них являются истинными позитивами, то есть реальными ошибками; игнорируя дубликаты библиотек, около 75% являются настоящими ошибками. Мы предлагаем, чтобы существовала технология для устранения уязвимостей в строках формата в ближайшем будущем.
Категории и предметные дескрипторы D.4.6 [Операционные системы]: безопасность и защита - инвазивное программное обеспечение; Общие условия: безопасность, языки; Ключевые слова: уязвимость форматирования строки, крупномасштабный анализ, вывод Typequali fier
Статический анализ, который находит реальные ошибки, стоит того, независимо от того, является ли он С++ или нет. Некоторые из них, как правило, довольно шумные, но если они могут поймать тонкие ошибки, такие как сопоставленные/неподписанные сравнения, вызывающие оптимизации, которые нарушают ваш доступ к массиву или из пределов доступа, они, безусловно, стоят усилий.
У бывшего работодателя у нас был Insure ++. Это помогло выявить случайное поведение (использование неинициализированного материала), которое Вальгринд не смог найти. Но самое главное: он помогает удалить ошибки, которые еще не были известны как ошибки.
Insure ++ - это хорошо, но дорого, поэтому мы купили только одну лицензию пользователя.