Comments 25
Смысл действия непонятен. Компилятору, который собирает бинарник, все равно как отформатирован исходник. Человек, которому не всё равно, читает исходники до сборки, а не после.
Я слышал, форматирование в IDE завезли.
Дело в том, что определённое форматирование требуют в компании. Якобы чтобы всё было однообразно и предсказуемо.
Я работал в нескольких компаниях и в 3 из 5 был свой стандарт отступов в коде.
Я работал в нескольких компаниях и в 3 из 5 был...
Вы за 12 лет работы сменили не менее 5 компаний?
Задач по программировать микроконтроллеры в России очень мало.
Даже если Вы найдёте работу, то Вы сделаете всё за год, даже если будете писать всего лишь по 150 строчек кода в день. У вас буквально Flash память закончится за год. Прошивки пишутся быстро, особенно когда есть заготовки программных компонентов: MCAL, драйверы ASIC чипов, connectivity, sensitivity, computing, storage и control.
Как только Вы напишите прошивку, начальство станет предлагать Вам заняться всяческими смежными обязанностями: технический писатель, сисадмин, тестировщик, чертёжник, схемотехник, тополог, рабочий в производстве на участок ручной пайки поверхностного монтажа, курьер лишь бы хоть как-то оставить Вас в этой организации.
Если Вы будете отказываться, говоря, что хотите программировать микроконтроллеры дальше, то Вас станут изживать как проблемного сотрудника, перестанут давать новые задачи, назначат какую-н скучную рутину (например искать на рынке самые дешевые выводные резисторы), или придумают какую-нибудь провокацию (часто с участием женщин), спровоцируют на конфликт.
В этой профессии все пути тупиковые:
1—Если Вы будете бестолковым программистом, то Вас будут изживать из организации как безнадежного растяпу.
2—Если Вы будете очень толковым сотрудником, то Вас тоже будут изживать из организации ещё более интенсивнее, только уже как явного конкурента.
Программисты микроконтроллеров в России коммерческому рынку нужны, но только как сезонные работники на одну прошивку (полгода-год), подобно тому как в Финляндии сезонно нанимают сборщиков клубники. А потом тебе снова метаться по собеседованиям, искать фриланс, out source.
Многие будут склонять тебя организовать ИП или работать удалённо как самозанятого. Это называется "предприниматель в спальне".
Поэтому да, в среднем программисты-микроконтроллеров в России за 10 лет меняют работу от 7 до 15 раз...
В программировании МК регулярная смена работы это даже достоинство.
Только так можно встретить и освоить передовой опыт в этой теме. Я, в частности, только в 4й организации по-настоящему программировать микроконтроллеры научился.
А первые три организации до сих пор в пещерном веке елозят мышкой в IAR. Останься я там, не было бы ни одного текста от aabzel на habr. Понимаете?
Я придерживаюсь следующей стратегии:
Озвучить всем стиль написания кода, включая отступы, расположение скобок и форматирование аргументов. В идеале, предоставить правила форматирования для популярных IDE.
Добавить прекоммит-хук, который будет запрещать заливать или мержить неправильно отформатированный код. В качестве альтернативы можно автоматически добавлять комментарии о неправильном форматировании в ревью.
После этого каждый разработчик может использовать тот инструмент, который ему удобен для форматирования. При необходимости, если стиль репозитория отличается от предложенного, можно либо сначала отформатировать весь код в едином стиле, либо фильтровать ошибки форматирования только в тех участках, где были внесены изменения.
Добавлю, что правила можно положить сразу в репу, современные ide отлично его применяют перед комитом сами, в прекомите можно оставить только проверку. Ну и в ci должна быть lint стадия, где форматирование тоже должно провериться (если залили без хуков)
Дополню ответ утилитой pre-commit или ручной pre commit hook чтобы не забыть отформатировать перед комитом в случае правки в другом редакторе.
Проблема в том, что не все используют git c его hook(ами).
У других Perforсe, Arcadia, SVN, Mercurial, или вовсе под в ZIP архиве (привет военное НИИ).
Вот и получается что встроить форматирование в скрпипт сборки это самый демократичный вариант.
У некоторых перечисленных уже есть precommit hook.
А ещё можно использовать git обёртку во многих случаях.
Zip архив ведь как-то создавался с системой контроля версий. Вот там и добавить.
При сборке конечно можно форматировать, только это не на каждую сборку стоит делать, а только на финальную иначе сборка будет занимать приличное время когда файлов будет много.
clang-format очень тонко кастомизируемый инструмент под множество стандартов или личных предпочтений пользователя. В статье полно абсолютно ненужной «воды», но при этом отсутствует главное — то самое заявленное в заголовке и поэтому ожидаемое описание как работать с clang-format, используя всю его мощь и множество настроек.
Не согласен. Сlang-format не настолько гибкий как надо.
Сlang-format, например, не может принудительно выравнивать аргументы функций в столбик.
Я нигде и не заявлял что clang-format «гибкий как надо», идеален или абсолютно универсален. Поэтому не совсем понятно с чем именно Вы не согласны.
Это просто инструмент. Кому-то он подходит, кому-то — нет. Лично мне — нет. Я хочу вот так, а он этого не умеет:
void add_string_to_array(
char ***array,
const char *another_array
){
int size = 0;
if(array != NULL)
{
while(array[size] != NULL)
{
size++;
}
}
}
А зачем выдумывать свое форматирование, если в Clang format нет для него опций?
Это же лишняя морока потом вручную всё расставлять.
Лично мне — нет. Я хочу вот так, а он этого не умеет:
И чем Вы тогда пользуетесь?
Пока ничем. В IDE, только, использую удаление лишних табуляторов, пробелов и пустых строк. Ищу консольный инструмент, который бы мне подходил и его можно было бы использовать в Makefile. Но пока все ранее перепробованные не удовлетворяют требованиям. Где-то код отформатируют как надо, а в других, самых неожиданных местах, только всё испортят.
Вам не жалко вертикального пространства монитора, из за переноса фигурных скобок на новую строку?
Для меня важно то, что строка сwhile(array[si...
визуально не прилипает к вышестоящей строке с if
if(arr...
Поэтому она чётко видна и такой код более читабельный. Акцентирую на том, что это моё личное предпочтение и настаивать на каких-то форматах по-умолчанию вообще не в моих правилах. Не зря только в clang-format уже заложены десятки детерминированных форматов — важна универсальность в рамках одной группы, совместно трудящейся над общим кодом.
Вам не жалко вертикального пространства монитора
Мне не жалко. У меня для кода отдельный, вертикально ориентированный монитор. Очень удобно!
И очевидно, что пользователям моего ПО будет вообще безразлично оформление. Никого из них не заботит изящность. Зато волнуют ошибки, которые могут появиться по вине разработчика из-за плохой читабельности кода. Поэтому если есть выбор, то код я оформлю так, чтобы для меня было удобно кодить, благодаря чему мне и только мне будет комфортно ориентироваться в написанном.
С такими предпочтениями в форматировании отступов вы наверно среди тех у кого монитор вертикально повёрнут.
Цель данного текста не научить пользоваться опциями clang-format , а показать, как интегрировать clang-format в процесс сборки прошивки.
Ему место в прекомит хуках, как писали выше или в чем-то подобном.
Какой толк от него в системе сборки?
del
Ему место в прекомит хуках, как писали выше или в чем-то подобном. Какой толк от него в системе сборки?
Хороший вопрос.
Дело в том, что далеко не все компании вообще используют системы контроля версий. Там даже понятие такое как "коммит" отсутствует.
Вот когда я работал в военном НИИ и мы писали прошивки для электронных плат внутри БМП-3 мы, например, прошивки передавали в *.zip архиве через USB флешку, или архивом по электронной почте.
Передавать прошивки (бинарники) можно разными способами, хоть на листочке хексы печатать.
Для таких организаций, где нет систем контроля версий проще в ide, или в редакторе кода настроить форматирование по хоткеям. Или в принципе не заниматься этим. Так как скорее программист единственный и о командной работе над одной кодовой базой тут речи и быть не может. Либо это будет сущим адом.
Форматирование отступов из-под системы сборки еще и тем хорошо, что вы можете к одной и той же кодовой базе в репозитории применять различные форматирования в зависимости от программного компонента. Например две команды разработчиков в одно репе работают.
В то время как форматирование git hook (ами) заставляет причесывать весь репозиторий под одну гребёнку. А это порой недопустимо.
Интеграция clang-format в Процесс Сборки