Является C++ статическим кодом analyis инструменты, стоящие того?

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

Я использовал их - Линт ПК, например, и они действительно находили некоторые вещи. Обычно они настраиваются, и можно сказать им, 'прекращают беспокоить меня о xyz', если Вы решаете, что xyz действительно не является проблемой.

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

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

Это действительно помогает. Я предложил бы брать пробную версию и выполнить ее через часть Вашей кодовой базы, которая Вы думаете, пропущен. Эти инструменты генерируют много ложных положительных сторон. Как только Вы пробрались через них, Вы, вероятно, найдете переполнение буфера или два, который может сохранить много горя в ближайшем будущем. Кроме того, попробуйте по крайней мере два/три варианта (и также часть материала OpenSource).

Те инструменты действительно помогают. линт был большим инструментом для разработчиков C.

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

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

Вот в чем разница между инструментом статического анализа FindBugs для Java и Инспектором IntelliJ. Я значительно предпочитаю последнего.

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

я когда-то работал над проектом, который имел 100,000 + предупреждения из компилятора... никакой смысл в рабочих инструментах Lint на той кодовой базе.

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

Так, да инструменты стоят того... в долгосрочной перспективе. В ближайшей перспективе поверните свои предупреждения компилятора до макс. и посмотрите то, о чем это сообщает. Если код является "чистым" тогда, время для рассмотрения инструментов линта теперь. Если код имеет много предупреждений... располагают по приоритетам и фиксируют их. Как только код не имеет ни одного (или по крайней мере очень немногие), предупреждения тогда смотрят на инструменты Lint.

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

Редактирование:

В случае 100,000 + предупреждение продукта, это было сломано приблизительно на 60 проектов Visual Studio. Поскольку каждый проект имел все предупреждения, удалил его, был изменен так, чтобы предупреждения были ошибками, которые препятствовали новым предупреждениям быть добавленными к проектам, которые были очищены (или скорее это позволило моему коллеге справедливо вопить на любого разработчика, который зарегистрировался в коде, не компилируя его сначала:-)

Я думаю, что статический анализ кода определенно стоит при использовании правильного инструмента. Недавно, мы попробовали Инструмент Coverity (укусил дорогой). Его потрясающее, это произвело много критических дефектов, которые не были обнаружены линтом или очищают.

Также мы нашли, что, возможно, избежали 35% потребительских Полевых дефектов, если бы мы использовали coverity ранее.

Теперь, Coverity реализован в моей компании и когда когда-либо мы получаем потребительскую TR в старой версии программного обеспечения, мы выполняем coverity против него для вывода наружу возможного canditates для отказа, прежде чем мы запустим анализ в susbsytem.

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

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

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

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

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

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

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

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

Wether или не инструмент стоит того, зависит от Вашей организации. Каковы виды ошибок, Вы - бит большинством? Они - ошибки переполнения буфера? Действительно ли они являются пустыми - разыменовывают или ошибки утечки памяти? Они распараллеливают проблемы? Они, "ой мы не полагали, что сценарий", или "не протестировали версию Chineese нашего продукта, работающего на литовской версии Windows 98?".

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

инструмент, вероятно, поможет с переполнением буфера, пустой указатель разыменовывают, и ошибки утечки памяти. Существует шанс, что может помочь с ошибками многопоточного выполнения, если это имеет поддержку "окраски потока", "эффектов" или анализа "полномочий". Однако те типы анализа являются довольно ультрасовременными, и имеют ОГРОМНЫЕ письменные трудности, таким образом, они действительно идут с некоторым расходом. Инструмент, вероятно, не поможет ни с каким другим типом ошибок.

Так, это действительно зависит от того, какое программное обеспечение Вы пишете, и с какими ошибками Вы сталкиваетесь наиболее часто.

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

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

Во-первых, разработчики, для кода которых нужен статический анализ больше всего, маловероятно для использования его добровольно. Таким образом, я боюсь, что Вам будет нужна сильная поддержка управления, на практике а также в теории; иначе это могло бы закончиться как просто объект контрольного списка, для создания впечатляющих метрик, на самом деле не получая исправленные ошибки. Любой инструмент статического анализа собирается произвести ложные положительные стороны; Вы, вероятно, испытываете необходимость для выделения кого-то уменьшению раздражения от них, например, путем сортирования дефектов, приоритизации средств проверки и тонкой настройки настроек. (Коммерческий инструмент должен быть чрезвычайно хорош в никогда показе лжи, положительной несколько раз; тот один может стоить цены.) Даже подлинные дефекты, вероятно, генерируют раздражение; мой совет относительно этого не состоит в том, чтобы волноваться о, например, комментарии регистрации, ворчащие, что очевидно разрушительные ошибки “незначительны”.

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

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

Я недавно написал общую тираду по этому поводу: http://www.redlizards.com/blog/?p=29

Я должен написать часть 2, как только позволит время, но в целом сделаю некоторые приблизительные вычисления, будет ли это стоит для вас:

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

Моё личное мнение также следующее:

• получить статический анализ в начале

  • в начале проекта
  • в начале цикла разработки
  • в самом начале (до ночной сборки и последующего тестирования )

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

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

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

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

1) Не включайте все сразу, определитесь с первоначальным набором дефектов, включите этот анализ и исправьте их во всей кодовой базе.

2) Когда вы обращаетесь к классу дефектов, помогите всей команде разработчиков понять, что это за дефект, почему он важен и как кодировать для защиты от этого дефекта.

3) Работайте над полной очисткой кодовой базы этого класса дефектов.

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

3) Работайте, чтобы полностью очистить кодовую базу от этого класса дефектов.

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

3) Работайте, чтобы полностью очистить кодовую базу от этого класса дефектов.

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