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

Вот буквально некоторые пункты из типичного внутреннего 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, а самостоятельно написанными скриптами сборки.

Ссылки