Мой босс считает, что любой код, который мы пишем (в C/С++), должен соответствовать стандартам, установленным инструментом статического анализа (например, MISRA/Lint). Я считаю, что компиляторы хорошо разработаны сегодня, действительно ли это необходимо?
Вопрос: насколько эффективен этот статический анализ в наши дни?
Короткий ответ: Да.
Длинный ответ: компиляторы действительно лучше разбираются в некоторых "ошибках", но "глубина", в которой они работают, как правило, намного меньше, чем правильные инструменты для этого. В частности, инструменты, которые работают с компиляционными модулями, такими как Coverity, которые могут понять (например), что функция может возвращать указатель как NULL, и если это произойдет, ваш код сработает, потому что вы не проверяете NULL перед доступом к указателю.
Инструменты статического анализа также могут проверять использование блокировки, чего обычно не может быть у компилятора.
Что касается "насколько эффективно", это действительно зависит от того, какой инструмент вы используете, какие настройки и насколько хорошо вы в противном случае проверяете код. Таким образом, в него также входит "покрытие кода". Проходите ли вы через каждую ветвь своего кода в своем тестировании? С любой возможной ценностью, которая вызывает разницу в поведении? Инструменты статического анализа могут обнаруживать ошибки, которые могут не покрыть ваши проверки.
(Очевидно, что действительно ли это имеет смысл в вашем конкретном бизнесе - это совершенно другое обсуждение - это для вашего босса и его/ее боссов)
Не то, чтобы компиляторы не могли выполнить анализ, который делают инструменты статического анализа. Проблема в том, что анализ статического кода занимает значительное количество времени и обычно не требуется для каждой отдельной компиляции. Компиляторы обычно оптимизированы для баланса качества кода и времени компиляции. Если компилятор случайно наткнулся на ошибку в коде, он скажет вам, но у него нет времени активно искать ошибки.
Кроме того, статический анализ важен для создания показателей.
Эти показатели могут показать: циклическую сложность, глубину наследования вашего класса и многие другие/зависимости граф /% комментариев и многое другое (Понять есть полный список функций, например).
Хорошим моментом является то, что большинство инструментов статического анализа позволяют добавлять определенные правила, которые могут быть полезны, если у вашего проекта/компании есть правила кодирования.
Вы также можете добавить сервер "Непрерывная интеграция" для проверки вашей ветки svn/ git/другого развития каждый день и провести анализ ночью. Таким образом, на следующий день вы можете исправить код, который не соответствует вашему набору правил.
Да, это добавляет больше уверенности в код.
Правила MISRA широко используются в системах реального времени. для выполнения многих программных аудиторов требуется соблюдение MISRA (путем использования инструмента, поддерживающего misra).
Также MISRA (или аналогичные стандарты) определяют некоторые громоздкие правила, запрещающие пользователю делать причудливые вещи, которые могут пойти не так, как на некоторых компиляторах. Например, арифметика указателей запрещена MISRA, но никакой компилятор не даст вам предупреждение.
EDIT: Другой пример: следующий код делает то, что многие люди не ожидают (x!= 1.1 из-за точности с плавающей запятой).
int main(int agrc, char** argv){
float x = 1.1;
if(x == 1.1)
printf("Yes!\n");
else
printf("OMG!\n");
return 0;
}
Это не обнаружено компиляторами (проверено на gcc 4.6 и clang 3.2). Но он обнаруживается почти всеми инструментами статического анализа.
Хорошие инструменты статического анализа анализируют вещи, такие как циклометрическая сложность и даже такие вещи, как "запах кода" (см. книгу рефакторинга Мартина Фаулера). Даже подсчет строк в файле или в функции - это подсказки, которые могут улучшить ваш код. Однако я не думаю, что Линт покрывает эти области.
Необходимы ли инструменты для статического анализа? Абсолютно. Предупреждения, испускаемые компиляторами, становятся все более сложными, но по-прежнему существует ограничение, что компилятор обычно работает в одном исходном файле за раз. Каждый файл скомпилирован (*.c → *.o), и итоговые файлы объектов связаны в конце. Чтобы сделать действительно эффективный статический анализ, вам нужно сразу просмотреть всю базу кода, проанализировать отдельные файлы, а также взаимодействия между ними. Компиляторы обычно не разработаны таким образом, поэтому сам компилятор обычно пропускает те вещи, которые статические анализаторы собирают. Вы не хотели бы создавать эту функциональность в обычном компиляторе, потому что это довольно тяжелое влияние на производительность. Статический анализ, выполняемый в моем текущем проекте, обычно занимает 4 раза, когда выполняется обычный компилятор. Вы не хотите лишних накладных расходов на каждую отдельную сборку, поэтому лучше всего использовать ее для отдельного специализированного инструмента, чем при необходимости (или, в случае некоторых современных компиляторов, отдельный набор параметров командной строки которые по умолчанию отключены).
Насколько эффективен статический анализ? Очень. Моя команда обнаруживает большое количество потенциальных проблем с помощью инструментов статического анализа, большинство из которых почти невозможно найти, используя другие методы. Это особенно полезно при поиске сложных проблем, которые люди не умеют находить, например, те, которые связаны с взаимодействием между несколькими локальными и глобальными переменными. Даже если у вас отличное покрытие для тестирования, статические анализаторы найдут всевозможные вещи, которые трудно найти только путем тестирования. Это еще более верно во встроенном мире, где тестирование имеет тенденцию быть более сложным и менее автоматизированным. По моему опыту, статические анализаторы даже показали нам проблемы, которые мы даже не знали, что нам нужно было тестировать в первую очередь.
Я бы определенно рекомендовал использовать инструменты статического анализа для любого нетривиального программного проекта. Я фактически запускаю два отдельных статических анализатора (один встроен в компилятор, а другой - отдельная утилита); вы можете быть удивлены тем, что поймать, а другое пропустит. Я настоятельно рекомендую вам придумать индивидуальный набор правил/тестов для ваших аналитических прогонов вместо простого принятия набора правил, такого как MISRA. Каждый проект нуждается в разных, и многие отраслевые спецификации, такие как MISRA, включают в себя множество вещей, которые не нужны большинству людей. Чем больше ненужных вещей, которые вы проверяете, тем больше времени требуется для анализа, тем больше ложных срабатываний вам придется пробираться и т.д. И т.д.