Интеграция Стилистического Анализа в общий Make Скрипт Сборки Проекта

В некоторых компаниях есть внутренние требования к стилю оформления исходных кодов на Си.

Вот буквально некоторые пункты из типичного внутреннего code-style:

1. Объявления функций должны в точности соответствовать их определениям

2. Базовые типы данных не должны использоваться в исходном коде, вместо них – переопределения

3. Все объявления и определения идентификаторов должны быть прокомментированы

4. В конце оператора выбора switch должен быть default case

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

6. Все параметры функций должны быть перечислены ‘в столбик’

7. В исходном коде не должно быть ‘магических чисел’

8. В исходном тексте не должно быть символов табуляции

9. В сложных выражениях везде должны стоять скобки

10. Для всех объявлений глобальных функций и переменных в h-файле обязательно ключевое слово ‘extern’

11. Ширина строки должна быть не более 80 символов

12. Все параметры макросов должны быть заключены в скобки

13. Функции без параметров должны содержать в скобках void

14. Тело конструкций if, else if, switch, for, while, do..while должно быть заключено в фигурные скобки

15. В одной строке должно быть не более одного определения

16. Исходный текст не должен содержать закомментированный код

17. Ко всем параметрам функций должен быть по возможности применен спецификатор ‘const’

18. В исходном коде не должно быть ‘магических чисел’: все символьные константы должны иметь осмысленные имена

19. и тому подобное вплоть до номера 463

У нас в организации есть даже python скрипт для автоматического выявления нарушений первых 18 правил оформления исходников. Не знаю кто его написал, но скрипт реально работает и находит некоторые нарушения. Процентов 10 от общего количества правил. Хоть что-то.

Постановка задачи

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

Что надо из софта?

Реализация

У меня есть Python скрипт autoverifier.py. Если запустить его на исполнение передав абсолютный путь к файлу с исходником, то в stdout вывалится лог о том, что скрипт упал

Однако в директории, из которой был вызван этот скрипт появится текстовый файл common_verifier_results.txt с отчетом о нарушениях и соответствиях code style.

========C:\xxx\xxx\xxx\xxxx\xxxx\xxxx\xxx\xxx\i2s_drv.c========   |      +  В исходном тексте не должно быть символов табуляции (СООТВЕТСТВУЕТ)   |      +  Ширина строки должна быть не более 80 символов (СООТВЕТСТВУЕТ)   |      +  Базовые типы данных не должны использоваться в исходном коде, вместо них – переопределения (СООТВЕТСТВУЕТ)   |      +  Функции без параметров должны содержать в скобках void (СООТВЕТСТВУЕТ)   |      +  Все параметры функций должны быть перечислены 'в столбик' (СООТВЕТСТВУЕТ)   |      +  В конце оператора выбора switch должен быть default case (СООТВЕТСТВУЕТ)   |      +  Тело конструкций if, else if, switch, for, while, do..while должно быть заключено в фигурные скобки (СООТВЕТСТВУЕТ)   |      +  В одной строке должно быть не более одного определения (СООТВЕТСТВУЕТ)   |      +  Исходный текст не должен содержать закомментированный код (СООТВЕТСТВУЕТ)   |     --- В исходном коде не должно быть 'магических чисел': все символьные константы должны иметь осмысленные имена (НЕ СООТВЕТСТВУЕТ) (НЕ СООТВЕТСТВУЕТ)   |       ->    В строке 753 обнаружено 'магическое число'   |       ->    В строке 825 обнаружено 'магическое число'   |       ->    В строке 915 обнаружено 'магическое число'   |       ->    В строке 1435 обнаружено 'магическое число'   |       ->    В строке 1494 обнаружено 'магическое число'   |     --- Ко всем параметрам функций должен быть по возможности применен спецификатор 'const' (НЕ СООТВЕТСТВУЕТ)   |       ->    В строке 1001 обнаружены аргументы ['Node'], к которым можно применить спецификатор 'const'   |       ->    В строке 1053 обнаружены аргументы ['clockBus'], к которым можно применить спецификатор 'const'   |      +  Все параметры макросов должны быть заключены в скобки (СООТВЕТСТВУЕТ)   |     [WW] Для данного исходного файла не был найден соответсвующий ему заголовочный файл   |     [WW] Для данного исходного файла не был найден соответсвующий ему заголовочный файл   |      +  Объявления функций должны в точности соответствовать их определениям (СООТВЕТСТВУЕТ)   |     --- Все объявления и определения идентификаторов должны быть прокомментированы (НЕ СООТВЕТСТВУЕТ)   |       ->    В строке 187 идентификатор не прокомментирован   |       ->    В строке 1401 идентификатор не прокомментирован   |       ->    В строке 1461 идентификатор не прокомментирован   |     --- В сложных выражениях везде должны стоять скобки (НЕ СООТВЕТСТВУЕТ)   |       ->    В строке 708 обнаружено сложное выражение без достаточного количества скобок   |       ->    В строке 753 обнаружено сложное выражение без достаточного количества скобок   |      +  Все локальные переменные функций должны быть проинициализированы до первого использования (СООТВЕТСТВУЕТ) 

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

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

При этом, меня не интересует, что хорошо. Меня интересует по каким пунктам code-style надо что-то исправлять. Поэтому надо также автоматически поудалять из локального отчета те строчки, которые содержат символ плюс.

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

Самое простое решение это воспользоваться системой сборки GNU Make. Вот так это выглядит в коде на языке программирования make.

$(info CodeStyleEhalScript)  include $(THIRD_PARTY_DIR)/code_style_files_to_check.mk  TOOLS_DIR = $(WORKSPACE_LOC)../tool TOOLS_DIR := $(subst /cygdrive/c/,C:/, $(TOOLS_DIR))  AUTO_VERIFIER_DIR=$(TOOLS_DIR)/AutoVerifier/Software AUTO_VERIFIER=$(AUTO_VERIFIER_DIR)/autoverifier.py   CODE_STYLE_TOOL = python $(AUTO_VERIFIER) SOURCES_CODE_STYLE_CSC := $(subst .c,.ccs, $(SOURCES_CODE_STYLE_C)) SOURCES_CODE_STYLE_CSH := $(subst .h,.csh, $(SOURCES_CODE_STYLE_H))   #@echo $(error SOURCES_CODE_STYLE__CS= $(SOURCES_CODE_STYLE__CS))  CODE_STYLE_TOTAL_REPORT = $(BUILD_DIR)/$(TARGET)_code_style_report.txt  CODE_STYLE_ONE_REPORT=$(MK_PATH)common_verifier_results.txt  clean_report: $(SOURCES_CODE_STYLE_H) $(info RunCleanCodeStyleReport)  "" > $(CODE_STYLE_TOTAL_REPORT)   %.csh: %.h $(info RunCodeStyleCheck for H file)  rm -f $(CODE_STYLE_ONE_REPORT) $(CODE_STYLE_TOOL) $< sed -i '/ + /d' $(CODE_STYLE_ONE_REPORT) cat $(CODE_STYLE_ONE_REPORT) >> $(CODE_STYLE_TOTAL_REPORT)  %.ccs: %.c $(info RunCodeStyleCheck for C file)  rm -f $(CODE_STYLE_ONE_REPORT) $(CODE_STYLE_TOOL) $< sed -i '/ + /d' $(CODE_STYLE_ONE_REPORT) cat $(CODE_STYLE_ONE_REPORT) >> $(CODE_STYLE_TOTAL_REPORT)  .PHONY: code_style code_style: $(SOURCES_CODE_STYLE_CSC) $(SOURCES_CODE_STYLE_CSH)  $(info CodeStyleCheckDone)  

Буквально несколько комментариев по коду…

Файлы, которые надо анализировать, можно явно указать в отдельном make скрипте code_style_files_to_check.mk

$(info AddFilesToCheckCodeStyle)  SOURCES_CODE_STYLE_C += $(THIRD_PARTY_DIR)/asics/nau8814/nau8814_driver.c SOURCES_CODE_STYLE_H += $(THIRD_PARTY_DIR)/asics/nau8814/nau8814_driver.h    ...... SOURCES_CODE_STYLE_C += $(THIRD_PARTY_DIR)/computing/dds/dds.c SOURCES_CODE_STYLE_H += $(THIRD_PARTY_DIR)/computing/dds/dds.h    SOURCES_CODE_STYLE_H := $(subst /cygdrive/c/,C:/, $(SOURCES_CODE_STYLE_H)) SOURCES_CODE_STYLE_C := $(subst /cygdrive/c/,C:/, $(SOURCES_CODE_STYLE_C))  

чтобы удалить из файла все строчки с символом + надо исполнить это

sed -i '/ + /d' file.txt

Я создаю мнимые расширения *.csh *.cсs только для того чтобы make догадался пробежаться по всем *.h *.c файлам. На самом деле *.csh *.cсs — это не файлы, а просто текст в переменной окружения.

Когда скрипт готов, то достаточно просто открыть в консоли cmd папку с проектом прошивки и выполнить команду

make -i code_style

После чего в папке с артефактами trunk\source\projects\config_name_m\build появится файл config_name_code_style_report.txt с полным отчетом по нарушениям внутреннего стандарта оформления исходных кодов для тех файлов, которые вы перечислили в code_style_files_to_check.mk.

Как видите, система сборки Make в очередной раз удружила. Оказывается, что через make скрипты можно не только собирать *.bin(ари), но и ещё можно добавить в сборку автоматическое генерирование отчета о соответствии вашего внутреннего code style.

Кто бы мог подумать…

Итоги

Удалось встроить скрипт автоматического выявления нарушений внутреннего code-style прямо в основной скрипт сборки прошивки.

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

Ссылки