В некоторых компаниях есть внутренние требования к стилю оформления исходных кодов на Си.
Вот буквально некоторые пункты из типичного внутреннего code-style:
Объявления функций должны в точности соответствовать их определениям
Базовые типы данных не должны использоваться в исходном коде, вместо них – переопределения
Все объявления и определения идентификаторов должны быть прокомментированы
В конце оператора выбора switch должен быть default case
Все локальные переменные функций должны быть проинициализированы до первого использования
Все параметры функций должны быть перечислены 'в столбик'
В исходном коде не должно быть 'магических чисел'
В исходном тексте не должно быть символов табуляции
В сложных выражениях везде должны стоять скобки
Для всех объявлений глобальных функций и переменных в h-файле обязательно ключевое слово 'extern'
Ширина строки должна быть не более 80 символов
Все параметры макросов должны быть заключены в скобки
Функции без параметров должны содержать в скобках void
Тело конструкций if, else if, switch, for, while, do..while должно быть заключено в фигурные скобки
В одной строке должно быть не более одного определения
Исходный текст не должен содержать закомментированный код
Ко всем параметрам функций должен быть по возможности применен спецификатор 'const'
В исходном коде не должно быть 'магических чисел': все символьные константы должны иметь осмысленные имена
и тому подобное вплоть до номера 463
У нас в организации есть даже python скрипт для автоматического выявления нарушений первых 18 правил оформления исходников. Не знаю кто его написал, но скрипт реально работает и находит некоторые нарушения. Процентов 10 от общего количества правил. Хоть что-то.
Постановка задачи
Сделать так, чтобы наравне с логом сборки прошивки и бинарями, появился также текстовый файл с отчетом о том, какие правила внутреннего стандарта нарушены и у казать в каком файле и на какой строчке в исходниках произошли эти нарушения.
Что надо из софта?
№ | Утилита | назначение |
1 | autoverifier.py | утилита для проверки внутреннего стандарта оформления программ |
2 | make | Утилита управления программным конвейером |
3 | cat | печать файлов в консоль |
5 | sed | консольная авто замена внутри текстовых файлов |
6 | python | интерпретатор языка phython |
7 | cmd | интерпретатор консоли в Windows |
Реализация
У меня есть 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, а самостоятельно написанными скриптами сборки.
Ссылки
№ | Гиперссылка |
1 | |
2 | |
3 | |
4 | |
5 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 |
