Есть такая утилита для автоматического выравнивания отступов в исходных кодах. Называется clang-format.exe. Надо признать, что сейчас де факто основной утилитой автоматического выравнивания отступов является именно утилита clang-format.exe из LLVM. Её достоинство в том что ей всё равно в каком текстовом редакторе вы пишите код. Что в Eclipse, что Notepad++, что MS Visual Code. Сlang-format он выровняет всё, что ему подадут на вход в соответствии с указанным конфигом в опциях командной строки.
Есть еще тоже консольный GNU indent, однако indent очень устарел и слаб. Плюс падает от обнаружения препроцессора.
Цель данного текста- показать, как интегрировать clang-format в процесс сборки прошивки.
Почему обычно делают форматирование отступов в исходниках?
На то я вижу минимум три причины:
1--Для однообразности и красоты. В каждой российской компании свой собственный, внутренний, ни на кого больше не похожий стандарт оформления исходных текстов программ на Си. Причем отличается обычно на 80%..90% от других организаций.
2--Чтобы был минимальный diff при сравнении разных по времени версий одного и того же куска Си кода
3--Чтобы можно было составлять простые и предсказуемые регулярные выражения для поиска шаблонов кусков кода утилитой grep и find в репозитории с кодом.
В чем проблема?
Проблем тут две:
1--Первая проблема в том, что вручную выставлять отступы это очень утомительно и рутинно. Однако эта проблема решается, как раз, утилитами автоматического выставления отступов.
2--Вторая проблема в том, что для автоматического форматирования кода утилитами приходится составлять *.bat файл и явно прописывать внутри какой файл надо форматировать. Это тоже очень рутинно с учетом, что файлов в сборке порядка нескольких сотен. Вот у меня типичная сборка собирает 237 с-файликов. И что, мне прописывать 237 строчки в bat файле что ли?
Очевидно же, что надо как-то автоматизировать процесс прогона с-файлов через утилиту форматировщик clang-format.
Решение
Попробуем запустить clang-format автоматически из скриптов сборки. Проще говоря, надо вмонтировать утилиту автоматического выравнивания прямо в систему сборки прошивки.
Что надо из софта?
# | Название утилиты | Назначение |
1 | grep | рекурсивный поиск по файловой системе |
2 | sed | утилита авто замены ключевых слов в файлах |
3 | make | утилита управления системой сборки |
4 | clang-format | утилита автоматического выравнивания исходных кодов |
Можно написать отдельный make файл для вызова этой утилиты. Вот по такой схеме.
Вот такой Make скрипт сам производит выравнивание тех же самых файлов, что участвовали в сборке прошивки.
$(info ClangFormatScript)
CLANG_FORMAT_TOOL =C:/cygwin64/bin/clang-format.exe
SOURCES_CF := $(subst .c,.cf, $(SOURCES_C))
#$(error SOURCES_CF=$(SOURCES_CF))
MCAL_STYLE="{
MCAL_STYLE+= BreakBeforeBraces: Attach,
MCAL_STYLE+= ColumnLimit: 120,
MCAL_STYLE+= IndentWidth: 4,
MCAL_STYLE+= PointerAlignment: Left,
MCAL_STYLE+= SortUsingDeclarations: true,
MCAL_STYLE+= SpaceBeforeParens: Never,
MCAL_STYLE+= SortIncludes: true,
MCAL_STYLE+= TabWidth: 4,
MCAL_STYLE+= UseTab: Never,
MCAL_STYLE+=}"
#$(error MCAL_STYLE=$(MCAL_STYLE))
%.cf: %.c
$(info RunClangFormat)
$(CLANG_FORMAT_TOOL) -verbose -i -style=$(MCAL_STYLE) $<
.PHONY: clang_format
clang_format: $(SOURCES_CF)
$(info ClangFormatDone)
Однако есть один момент. Не все файлы исходников следует подвергать автоматическому выравниванию. Дело в том, что если ты меняешь форматирование в файле, то ты, как бы, автоматически становишься владельцем этого кода. Оно тебе надо? Ты же не хочешь нести ответственность за этот странный чужой код просто потому, что ты там поменял TAB на 4 пробела? Поэтому существует такое негласное правило буравчика:
Ни в коем случае нельзя менять форматирование в чужом коде!
Очевидно, что в скриптах сборки надо как-то пометить те файлы сорцов, которые мы не будем форматировать. Это могут быть сорцы с конфигурационными таблицами для GPIO, таймеров.
Надо чтобы они и остались в первозданном виде таблиц.
Дак вот, в системе сборки make сделать это очень просто. Надо всего-навсего проиндексировать чужие сорцы в переменную окружения SOURCES_THIRD_PARTY_C.
ifneq ($(FAT_FS_MK_INC),Y)
FAT_FS_MK_INC=Y
FAT_FS_DIR += $(THIRD_PARTY_DIR)/fat_fs
#@echo $(error FAT_FS_DIR= $(FAT_FS_DIR))
INCDIR += -I$(FAT_FS_DIR)
INCDIR += -I$(FAT_FS_DIR)/src
INCDIR += -I$(FAT_FS_DIR)/src/options
SOURCES_THIRD_PARTY_C += $(FAT_FS_DIR)/src/diskio.c
#SOURCES_THIRD_PARTY_C += $(FAT_FS_DIR)/src/option/unicode.c
SOURCES_THIRD_PARTY_C += $(FAT_FS_DIR)/src/option/ccsbcs.c
SOURCES_THIRD_PARTY_C += $(FAT_FS_DIR)/src/ff.c
endifЕсли лень это производить вручную, то можно применить этот bash скрипт
grep -rl SOURCES_C . | xargs sed -i 's/SOURCES_C/SOURCES_THIRD_PARTY_C/g'
grep -rl SOURCES_C . | xargs sed -i 's/SOURCES_C/SOURCES_CONFIGURATION_C/g'Далее в rules.mk просуммировать те сорцы, которые мы форматируем SOURCES_C и те, которые мы не форматируем SOURCES_THIRD_PARTY_C в одну переменную окружения SOURCES_TOTAL_C
SOURCES_TOTAL_C += $(SOURCES_C)
SOURCES_TOTAL_C += $(SOURCES_THIRD_PARTY_C)
SOURCES_TOTAL_C += $(SOURCES_CONFIGURATION_C)
SOURCES_TOTAL_C := $(subst /cygdrive/c/,C:/, $(SOURCES_TOTAL_C))
Вот так получается, что THIRD PARTY и CONFIGURATION код останется без изменений. Всё что надо - это открыть папку с проектом из консоли и набрать
make clang_formatВсе нужные с-файлы станут с выровненными отступами. Автоматически... Крастота!
Достоинства форматирования из-под скриптов сборки (Make)
++Форматирование отступов из-под системы сборки тем хорошо, что вы можете к одной и той же кодовой базе в репозитории применять различные форматирования в зависимости от программного компонента. Например две команды разработчиков в одно репе работают.
В то время как форматирование git hook (ами) заставляет причесывать весь репозиторий под одну гребёнку. А это порой недопустимо.
++Дело в том, что далеко не все компании вообще используют системы контроля версий. Там даже понятие такое как "коммит" отсутствует. Вот в секретном военных НИИ мы писали прошивки для электронных плат и прошивки передавали в *.zip архиве через USB флешку, или архивом по электронной почте. Никакой системы контроля версий вообще не было из-за конспирации.
Итоги
Как видите, сборка из скриптов (в частности make) дает такие преимущества как автоматическое выравнивание отступов исходного кода.
Понятное дело, что если вы собираете программы из IDE мышкой, то вам такое не доступно в принципе. Поэтому имеет смысл задуматься о переносе на сборки скриптами.
А с Make удалось с полпинка вмонтировать утилиту clang-format в основной конвейер сборки прошивки. Успех!
Словарь
акроним | расшифровка |
LLVM | Low Level Virtual Machine |
bash | Bourne again shell |
GNU | GNU’s Not UNIX |
sed | Stream EDitor |
grep | search Globally for lines matching the Regular Expression, and Print them |
Ссылки
