Существуют ли удобные инструменты для автоматической проверки соглашений о кодировании C++ за пределами проверки стиля?

Я запустил ряд инструментов статического анализа в своем текущем проекте, и вот некоторые из ключевых выводов:

• Я Визуальный Линт как единая точка входа для запуска всех этих инструментов. VL-это плагин для VS для запуска сторонних инструментов статического анализа и позволяет одним щелчком мыши маршрутизировать из отчета в исходный код. Помимо поддержки GUI для выбора между различными уровнями ошибок, он также обеспечивает автоматизированный фон анализ (который говорит вам, сколько ошибок было исправлено, как вы идете), ручной анализ для одного файла, цветные дисплеи ошибок и средство построения графиков. Установщик VL довольно изящен и чрезвычайно полезен, когда вы пытаетесь добавить новые инструменты статического анализа (это даже поможет вам загрузить Python из ActiveState, если вы хотите использовать Google cpplint и не имеете предустановленного Python!). Вы можете узнать больше о VL здесь: http://www.riverblade.co.uk/products/visual_lint/features.html

• из многочисленных инструментов, которые можно запустить с VL, я выбрал три, которые работают с родным кодом C++: cppcheck, Google cpplint и Inspirel Vera++. Эти инструменты имеют различные возможности.

• Cppcheck: это, вероятно, самый распространенный, и мы все его использовали. Так что я замалчиваю детали. Достаточно сказать, что он ловит ошибки, такие как использование postfix приращение для непримитивных типов предупреждает об использовании size() при использовании empty (), уменьшении области переменных, неправильной квалификации имен членов в определении класса, неправильном порядке инициализации членов класса, отсутствующих инициализациях, неиспользуемых переменных и т. д. Для нашей кодовой базы cppcheck сообщил об ошибках 6K. Было несколько ложных срабатываний (например, неиспользуемая функция), но они были подавлены. Вы можете узнать больше о cppcheck здесь: http://cppcheck.sourceforge.net/manual.pdf

• Google cpplint: это инструмент на основе python, который проверяет ваш источник на наличие нарушений стиля. Руководство по стилю, с которым выполняется эта проверка, можно найти здесь:http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml (который в основном является руководством Google по стилю C++). Cpplint произвел ~ 104K ошибок с нашей кодовой базой, из которых большинство ошибок связаны с пробелами (отсутствует или дополнительно), вкладки, положение скобки и т. д. Несколько, которые, вероятно, стоит исправить: слепки в стиле C, отсутствующие заголовки.

• Inspirel Вера++: это программируемый инструмент для проверки, анализа и преобразования исходного кода на языке C++. Это похоже на cpplint в функциональности. Список доступных правил можно найти здесь:http://www.inspirel.com/vera/ce/doc/rules/index.html и аналогичный список доступных преобразований может можно найти здесь:http://www.inspirel.com/vera/ce/doc/transformations/index.html. Подробности о том, как добавить свое собственное правило, можно найти здесь:http://www.inspirel.com/vera/ce/doc/tclapi.html. Для нашего проекта Vera++ найдено около 90K проблем (для 20 нечетных правил).

на предстоящих состояние: Мануэль Климек из Google интегрирует в магистраль Clang инструмент, который был разработан в Google для запроса и преобразования кода C++.

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

• Google создал простой набор C++ классы и методы, позволяющие запрашивать AST дружественным способом: структура AST Matcher, она разрабатывается и позволит очень точное соответствие в конце.

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

пример Матчера (найти в этой теме): цель это найти вызовы перегрузки конструктора std::string образовались в результате std::string::c_str() (с распределителем по умолчанию), потому что его можно заменить простой копией.

ConstructorCall(
    HasDeclaration(Method(HasName(StringConstructor))),
    ArgumentCountIs(2),
    // The first argument must have the form x.c_str() or p->c_str()
    // where the method is string::c_str(). We can use the copy
    // constructor of string instead (or the compiler might share
    // the string object).
    HasArgument(
        0,
        Id("call", Call(
            Callee(Id("member", MemberExpression())),
            Callee(Method(HasName(StringCStrMethod))),
            On(Id("arg", Expression()))
        ))
    ),
    // The second argument is the alloc object which must not be
    // present explicitly.
    HasArgument(1, DefaultArgument())
)

Это очень перспективно по сравнению с инструментом ad-hoc, потому что он использует библиотеку компилятора Clang AST, поэтому не только гарантируется, что независимо от того, насколько сложны используемые макросы и шаблоны, пока ваш код компилируется, он может быть проанализирован; но это также означает, что усложняет запросы, которые в зависимости от результата перегрузки разрешение может быть выражено.

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

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