Я работаю над большой, старой, но активно развивающейся базой кода C / C ++, где использование #define для управления аспектами кода во время компиляции является обычной практикой. Например, обычно определяют -DTARGET_HAS_FEATURE в файле Makefile, а затем используют его в коде:
#ifdef TARGET_HAS_FEATURE
// ... conditionally included code
#endif
Проект является многоцелевым и кросс-платформенным, поэтому с некоторыми причудами, понятно, легче справитьсяумным использованием препроцессора. Однако у меня есть сильное чувство, что на текущем этапе такие макроопределения используются чрезмерно, и я хочу держать их под контролем. По сути, они рассматриваются как глобальные нетипизированные переменные, которые удобно использовать некоторым разработчикам. Излишне говорить, что это чрезвычайно усложняет понимание того, что на самом деле делает код, и иногда скрывает ошибки.
Вопрос здесь такой: Существуют ли какие-либо подходы к анализу среды, в которой работает препроцессор, в рамкахпроект , а отчетность, если определенные свойства не держатся? Ответом может быть, по сути, инструмент статического анализатора кода, предназначенный для языка препроцессора, но это может быть флаг существующего программного обеспечения препроцессора, руководство по стилю кода или любой другой метод, предназначенный для устранения известных слабых свойств макроязыка в существующей кодовой базе.
Среди свойств, которые я хотел бы проверить:
- Существуют ли объявленные определения, которые никогда не используются в одном месте кода (неиспользуемые переменные).
- Существуют ли блоки
#ifdef - #endif, которые ссылаются на имя, никогда не определенное в каком-либо файле (неопределенные переменные). - Используется ли одно и то же макроопределение как в def / undef, так и в арифметических выражениях (типнарушение).
- Переопределено ли макроопределение (изменение константной переменной)
- Не слишком ли велик уровень вложенности выражений
#ifdef - #endif (проблема читабельности кода).