Comments 106
По-хорошему надо ещё лексический контекст учитывать.
Если в вашем исходнике поменять местами case '{' и case '}' и подать его на вход самому себе, то ему не захорошеет (хотя он и так нарушает проверяемое им же самим правило).
А если совсем строго, то надо раскрывать макроподстановки.
Вопросы--Зачем в конце if(...) {} писать if(...) {} // end of if(...)
Фортран своими руками.
поидее если считаем { +1 а } -1(где 1 - это 2 пробела допустим), но если учесть функционал что просто скобочку на новую строку поставить(если открывающая скобочка в конце строки ) и попутно удаляя табы перед строкой и в конце строки, а код при этом компилируется, то поидее не плохой форматер выходит, а так да надо поидее все токены ловить и по новой простраивать как я понимаю по хорошему
Хороший совет.
А еще я при парсинге файлов конфигурации 1С (которые в SQL в dbo.Config лежат, а в файловых базах в таблицах .dt файла) сталкивался с ситуацией, когда в комментариях к реквизиту/объекту была открывающая фигурная скобка, но не было закрывающей. И это тоже ломало CLR сборку, пока не добавил в нее обработку комментариев.
Не надо раскрывать макроподстановки. Если макросы нарушают баланс скобок или делают ещё что-то, что помешает работе такого анализатора – то они помешают и человеку читать код, а значит, должны быть переписаны.
В программировании микроконтроллеров, кажется лишним закрывать блоки комментариями, т.к. внутри этого блока можно легко встретить оптимизационную дичь вроде goto-инструкций.
А Можно Ваш Стилистический-Анализатор Как-то Приспособить К Правке Заголовков Статей?
тема классная, я форматер писал для интереса (парсер + форматер - как раз по этим скобочкам ориентировался)
Если бы мне вдруг понадобилось решать подобную задачу - моя программа сама бы расставляла правильные комментарии.
Если бы мне вдруг понадобилось решать подобную задачу - моя программа сама бы расставляла правильные комментарии.
То, что мы сейчас прочитали - это именно то, что нужно для решения всей проблемы.
Предлагаю Вам @randomsimplenumber до конца месяца написать, эту утилиту и написать тут на habr пояснительную записку про неё.
Чтобы уже в ближайшее время можно было автоматически проставлять корректные комментарии // end of xxx(...) после закрывающихся фигурных скобок во всем *.c файле.
Если бы мне вдруг понадобилось ;)
Ключевое слово выделено жирным.
Сколько платите за решение?
Угу. Для линтеров такая возможность – база. А ещё удобнее плагин к используемой IDE, который подсказывает эти подстановки.
А можно узнать какую проблему решает это правило? Не имел опыта с программированием микроконтроллеров, возможно, поэтому правило выглядит надуманным
какую проблему решает это правило? .... правило выглядит надуманным
Вот именно, дружище, что это правило никакой реальной проблемы не решает.
Вы правы. Правило комментария после } - это самое настоящее надуманное правило.
У нас в организации таких правило больше 400+ и у нас регулярно в чатах люди жалуются на то, что внутренний код-стайл давно доведён до абсурда.
Такую проблему стоит решать иначе — уходить из этой организации.
На самом деле это даже здорово придумывать всё новые и новые требования к code style. Так можно аргументировать раздувание фронта работ начальству, что тебе и коллегам гарантирована оплачиваемая работа на обозримую перспективу. Можно годами как пиявка высасывать из компании зарплату за то, что с меньшими требованиями к code style можно сделать максимум за 2-3 месяца
На самом деле это даже здорово
Ну, если всё всех устраивает - в чем проблема то? Автоматических средств проверки ваших 400 правил хорошего тона нет, цензурится вручную, но не очень строго. Написание 400 костылей займёт 400 * 2 дня = почти 3 года. И то, за это время могут ещё правил придумать. Если уж пилить - то что-то новое для себя, а не повторение темы, которую проходили когда то на 2 курсе. AI модная тема, flex - хз что это но выглядит интересно, ну и прочее ненормальное программирование ;)
Зачем уходить ,если за код стайл тут платят зарплату? И не маленькую...
При этом писать комменты это много проще, чем чинить чужие баги на новой работе.
правило выглядит надуманным
Вот, можете ознакомиться с полным нашим парадом абсурда
Потёмкинская Деревня в Коде
https://habr.com/ru/articles/837396/
А использовать проверенную десятилетиями связку flex+bison было слишком страшно?
Это ведь идеальная задача для парсера и грамматики.
Учитывая, что судя по вашему описанию - ваша утилита будет глючить на
комментариях, содержащих фигурные скобки
строковых литералах, содержащих фигурные скобки
символьных литералах, содержащих фигурные скобки
В общем, советую переделать по-взрослому.
Кстати, если немного подумаете - то сможете не просто проверочную утилиту реализовать, а реализовать утилиту, которая автоматом будет вставлять эти комментарии.
То, что мы сейчас прочитали - это именно то, что нужно для решения всей проблемы.
Предлагаю Вам @aeder до конца месяца написать, эту утилиту и написать тут на habr пояснительную записку про неё.
Чтобы уже в ближайшее время можно было автоматически проставлять корректные комментарии // end of xxx(...) после закрывающихся фигурных скобок во всем *.c файле.
А использовать проверенную десятилетиями связку flex+bison было слишком страшно?
Критикуешь- предлагай
Предлагая - делай
Делая - отвечай
Все три утверждения - манипулятивная стратегия защиты в дискуссии.
Вы хоть знаете кому принадлежат эти слова?
Ссылка на авторитет -- не менее манипулятивная стратегия. У вас нет аргументов в защиту вашего утверждения, так что вам не остается ничего, кроме как сослаться на кого-то, кто более уважаем, чем вы, в надежде, что это сделает вашу точку зрения весомее.
Просто развелось очень много, мягко говоря, Емеля-советников типа @aeder с нулевым количеством публикаций...
Я не знаю, кому принадлежат эти слова. Так как услышал я их от вас, то буду благодарен, если вы сможете аргументировать, почему нельзя критиковать что-либо, не предлагая решения? Например, я ничего не понимаю в теплоснабжении жилых кварталов в своем городе, значит ли это, что я не должен критиковать коммунальную службу, которая меня в морозы оставила с холодными батареями на двое суток? Я совершенно искренне не знаю, что именно им нужно улучшить у себя, чтобы такое не происходило, я не теплотехник и не управленец. Мне точно из-за этого нужно молчать? Также, переходя к пункту 2 и 3 вашего утверждения, нужно ли мне молчать, если я не готов устранить эту аварию самостоятельно и взять на себя ответственность за качество ремонта?
Судя по всему элементарная задача по строковому интерпретатору формул (скобочки определяют порядок расчета). В 90-м решали такую на конкурсе Юный программист с использованием ПЭВМ Правец-8А
В конце каждого блока if(...) {...} ; switch(...) {...} ; for(...) {...} и т.п. необходимо пиcать комментарий // end of if(...). end of switch(...) end of for(...) соответственно.
Тоже так делаю, потом удобнее смотреть, где конец чего. Но, конечно, в абсолют не возвожу.
С другой стороны, я пишу сам для себя программы для мелких микроконтроллеров, вплоть до PIC10 (512 байт ПЗУ, 64 байта ОЗУ, 200-300 строк кода). Возможно, при совместной работе над более крупными проектами подобные правила имеют смысл, даже если кажутся бесполезными и драконовскими?
Обычно если сходу по "ёлочке" не видно начало блока – надо рефакторить, вынося куски кода в отдельные функции.
вынося куски кода в отдельные функции.
Да. Однако у нас в организации есть другое правило, которое блокирует этот процесс.
"Порядок объявления функций должен совпадать с порядком определения функций."
Это подрывное правило исключает возможность создания большого количества маленьких Cи-функций, которые помещаются на один экран.
Дело в том что штатным программистам лень потом вручную сортировать функции по порядку объявления.
Из-за этого правила программисты предпочитают создавать 3, максимум 5 - мега функций-богов по тысяче строк в каждой, которые делают всё.
И это убивает модульность, читаемость, тесто пригодность и восприятие кода другими сотрудниками.
Это самый настоящий anti-pattern программирования.
Да, вот так, господа...
Порядок объявления функций должен совпадать с порядком определения функций
Дюра лекс конечно, но есть ли этому правилу непротиворечивое объяснение? Или это из тех домезозойских времён, когда текст программы нужно было распечатать на АЦПУ?
Уже обсуждали вот
https://habr.com/ru/articles/844436/#comment_27317592
Автор требования по ходу аутист. Он и в офисе себя ведет странно.
К таким надо относиться с пониманием...
Ну не знаю, не вижу проблем в поддержании порядка объявления функций (сортировать-то можно не порядок определения, а порядок объявления), вплоть до того, что доработать ваш линтер, чтобы он сам их сортировал :-)
Ну не знаю, не вижу проблем в поддержании порядка объявления функций (сортировать-то можно не порядок определения, а порядок объявления), вплоть до того, что доработать ваш линтер, чтобы он сам их сортировал :-)
А теперь представьте каково это, когда у вас в файле 120+ функций...
При этом на порядок объявления в *.h файле у нас в организации тоже есть свои правила.
Нельзя просто так взять и расставить как хочешь сигнатуры.
Сначала init потом deinit потом setter в конце getters.
Два дня пишешь функционал, а потом неделю меняешь порядок определения функций.
Зачем тратить на это время-деньги организации?
Тут проблема не в том, что их 120, а в том, что файл разросся.
Хотя меня в C/C++ вообще бесит необходимость написания заголовка функции в двух местах. Наследие древних времён, когда придумали подключать модули через текстовое включение файлов...
Зачем тратить на это время-деньги организации?
Организация этого требует - организация платит. Справедливо. Зачем решать рабочие вопросы бесплатно?
Организация этого требует - организация платит. Справедливо.
Да. Любой каприз за счёт организации.
Вот только это правило придумал конкретный человек. Больше это правило никому не нужно. И, получается, организация платит за его капризы.
В пересчете на ЗП разработчикам, которые везде это правило проставляют получаются огромные деньги убытков.
Один вместо использования инструментов, постоянно показывающих шапку блока на экране вводит правила по ее копированию в конец блока. Другой вместо написания тула автоматически добавляющего комментарии делает тул, который лишь показывает где их нет. И никого не смущают файлы на 5к строк и язык разработки из мезозоя. Я бы вас обоих даже джунами не взял, ибо тут наблюдается полная ментальная проф непригодность - программисты, не способные автоматизировать даже свою работу.
И язык разработки из мезозоя
Вы, Дмитрий, не забывайте, что это хаб программирования микроконтроллеров. А производители микроконтроллеров сами рекомендуют именно си для разработки.
Ну так и используйте современную его версию: https://habr.com/ru/articles/511334/
Боюсь мировое сообщество embedded разработчиков Вас (как front-end программиста) не поймет.
Если Вы не в курсе, то внутри микроконтроллеров ARM ядро. И для его запуска компания ARM дает CMSIS код, который написан на чистом Си.
Вот предложите британскому ARMу переписать CMSIS на D.
А потом напишите нам, что они Вам ответили.
Я смотрю Вы (как представитель embedded разработчиков) традиционно поленились прочитать статью, от чего и высказываете глупые гипотезы о необходимости переписывания стороннего кода.
Вообще-то это ничего не значит. Ядро Линукс тоже на С написано.
Что, из-за этого С++ не пользоваться?
Под современные микроконтроллеры спокойно можно писать на С++, т.к. clang и gcc пофиг, что преобразовывать в машинный код.
И да, при желании - с использованием урезанной стандартной библиотеки (без ввода/вывода), т.е. запросто можете пользоваться std::map и std::string. Если это удобно разработчику.
Да, надо иметь в виду, что использование динамической памяти на микроконтроллере - может привести к неожиданным результатам, но при грамотном использовании - более чем полезно.
Да чего, уж, мелочиться! Нужно сразу брать Haskell =) Что мы с успехом и сделали!
и язык разработки из мезозоя
Ну, в микроконтроллерах вариантов не особо много - или использовать язык из эпохи мезозоя, или для мигания светодиода придется ставить контроллер из эпохи Бака Роджерса.
Скрытый текст
Один вместо использования инструментов, постоянно показывающих шапку блока на экране вводит правила по ее копированию в конец блока.
Дело в том что тот человек, который придумывает у нас правила кодстайла обладает слишком низкой квалификацией, чтобы разбираться в инструментах и тем более в их разработке
тот человек, который придумывает у нас правила кодстайла обладает слишком низкой квалификацией, чтобы разбираться в инструментах и тем более в их разработке
Тогда возникают сомнения в квалификации человека, который поручил ему придумывать правила кодстайла. Мы же не позволяем людям, которые не разбираются в какой-то области деятельности, придумывать законы для нее? Wait...
Другой вместо написания тула автоматически добавляющего комментарии делает тул, который лишь показывает где их нет.
Ну знаешь...
Компилятор тоже не чинит найденные ошибки, а только лишь показывает факт наличия ошибок.
А неявное приведение типов кто делает, если не компилятор?
Компилятор – нет, а вот IDE предлагает автоматический фикс. Или вот eslint – у него есть флаг --fix, когда он записывает в файл предлагаемые правки (потом смотришь в git, что же он поменял, и коммитишь нужное).
Да и вашу тулзу не так уж трудно допилить, добавив такой ключик. Всё равно храните стек строк с открывающейся скобкой – никто не мешает оттуда строки брать и записывать в выходной файл.
И никого не смущают файлы на 5к строк
А сколько по вашему максимум в файле должно быть строк кода?
На уровне HAL используем C, в бизнес-логике C++. И производители микроконтроллеров тоже пишут библиотеки на C. Не на D, прошу заметить, не на Rust, не на Python, не на Go, и ни на чём другом. Вот таки мы странные ребята.
Да просто парень @nin-jin front-ender не туда зашёл по ошибке. Он не со зла.
не туда зашёл по ошибке
Наши сообщения об ошибках ему не понравятся...
Скрытый текст
Да. Именно так.
И чтобы таких вот ошибок не было, нужно подписывать закрывающие скобки комментариями и размещать функции в определенном порядке, правильно?
Не нахожу причинно-следственной связи.
Вы используете язык, переполненный UB, что приводит к непредсказуемому проведению программы, но вместо решения этой проблемы, играетесь с форматированием. И кто из нас фронтендер после этого?
Если что, то я вообще против любых комментариев к коду. Просто на работе заставляют их писать в огромном количестве.
Как по мне, хороший код понятен и без комментариев.
А упор надо делать на модульных тестах
Как по мне, хороший код понятен и без комментариев.
Комментарии хранят информацию, за которой иначе пришлось бы куда-то лезть:
const unsigned char TMR0LoadValue=61; // 40Hz/25ms interrupt rate @1MHz & 1:32 prescaler
FVRCON=0b10000001; // FVR and temp sensor; disable ADFVR before sleep for minimum power consumption!
PRR=0b00001111; // Power Reduction Register, see PDF page 38Позволяют напомнить себе будущему (или другому несчастному, который полезет в этот код), что именно происходит в данном месте:
if ((runMode==2)&&(distanceToGo==0)) // failed to trigger the sensor
digitalWrite(ENA,LOW); // just in case, the driver is always on anyway
digitalWrite(0,1); // data line high to prevent phantom powering the LEDsНу или просто так, чтоб было:
wdt_reset(); // woof!const unsigned char TMR0LoadValue=61; // 40Hz/25ms interrupt rate @1MHz & 1:32 prescaler
FVRCON=0b10000001; // FVR and temp sensor; disable ADFVR before sleep for minimum power consumption!
PRR=0b00001111; // Power Reduction Register, see PDF page 38Боже мой какой хардкод!
Не показывайте это никому... Прошу Вас.
Крайне рекомендую Вам ознакомится с этим текстом
https://habr.com/ru/articles/683762/
Архитектура Хорошо Поддерживаемого драйвера для I2C/SPI/MDIO Чипа
и Вы забудете, что такое комментарии в Си
Идут годы, а остроконечники никак не победят тупоконечников ;)
Боже мой какой хардкод!
Это не универсальный драйвер. Это программа, которая будет работать на одном железе, с одной частотой, с одними настройками таймеров. Предлагаете не хардкодить, а вынести все эти настройки - которые НИКОГДА не будут меняться - в отдельное место? Просто чтоб было по феншую?
Иногда хочется запустить программу на другом железе. А переписывать не хочется.
Иногда хочется запустить программу на другом железе. А переписывать не хочется.
А придется. Или переписывать, или изначально писать программы, учитывающие все возможные варианты железа. И вместо "FVRCON=0b10000001" будет три конфигурационных файла, пять библиотек и десять трудноуловимых багов. И все равно в итоге придется что-то исправлять.
Предлагаете не хардкодить, а вынести все эти настройки - которые НИКОГДА не будут меняться - в отдельное место? Просто чтоб было по феншую?
Надо придерживаться методологии
код отдельно, конфиги отдельно.
Это требование ISO26262
Вот текст про это
ISO 26262-6 разбор документа (или как писать безопасный софт)
https://habr.com/ru/articles/757216/
Надо не hardcode(ить) битовые константы как тут (Боже упаси...)
const unsigned char TMR0LoadValue=61; // 40Hz/25ms interrupt rate @1MHz & 1:32 prescaler
FVRCON=0b10000001; // FVR and temp sensor; disable ADFVR before sleep for minimum power consumption!
PRR=0b00001111; // Power Reduction Register, see PDF page 38 а создавать константные битовые поля и присваивать им именованные перечисления (слыхали про enum в Си?).
Тогда и // /**/ комменты нужны будут как собаке бензобак.
Понимаете?
Вот так надо
const Ltr390Register_t Ltr390Register[]={
{
.address=LTR390_REG_ADDR_MEAS_RATE,
.value.MeasRate={ .rate=LTR390_RATE_25_MS,
.resolution=LTR390_RESOLUTION_CODE_20_BIT, },
},
{
.address=LTR390_REG_ADDR_GAIN,
.value.AlsUvsGain={ .gain=LTR390_GAIN_CODE_18},
},
};
Почитайте про битовые поля в Си. Узнаете что это такое.
а создавать константные битовые поля и присваивать им именованные перечисления
Нафига? Данная битовая константа берется один раз из даташита и в ходе разработки данной прошивки не меняется. Это все равно что номер квартиры на двери сделать не двумя жестяными цифрами, прикрученными шурупами, а в виде электронного табло, на котором можно задавать числа от -32768 до +32767.
Вы используете язык, переполненный UB, что приводит к непредсказуемому проведению программы
У компилятора GCC так много ключей для ловли UB что достаточно только собрать бинарь с пучком опций
-Werror=address -Werror=switch
-Werror=array-bounds=1 -Werror=comment -Werror=div-by-zero
-Werror=duplicated-cond -Werror=shift-negative-value
-Werror=duplicate-decl-specifier -Werror=enum-compare
-Werror=uninitialized -Werror=empty-body
-Werror=unused-but-set-parameter
-Werror=unused-but-set-variable -Werror=float-equal
-Werror=logical-op -Werror=implicit-int
-Werror=implicit-function-declaration
-Werror=incompatible-pointer-types
-Werror=int-conversion -Werror=old-style-declaration
-Werror=maybe-uninitialized -Werror=redundant-decls
-Werror=sizeof-pointer-div -Werror=misleading-indentation
-Werror=missing-declarations -Werror=missing-parameter-type
-Werror=overflow -Werror=parentheses -Werror=pointer-sign
-Werror=return-type -Werror=shift-count-overflow
-Werror=strict-prototypes -Werror=unused-but-set-variable
-Werror=unused-function -Werror=missing-field-initializers
-Werror=unused-variable -Werror=unused-but-set-variable
-Werror=implicit-function-declaration
-Werror=unused-variable
и всё обычно хорошо. По крайней мере проблем никогда не было.
Старость Си это наоборот достоинство так как именно поэтому появились очень зрелые компиляторы. Даже бесплатный ARM-GCC 2021 года.
int main(void) {
int arr[4] = {0, 1, 2, 3};
return arr[5];
}https://godbolt.org/z/xKTPz4zzh
Мне страшно даже представить, сколько в вашем коде ещё не обнаруженных уязвимостей.
Модульные тесты проходят - значит всё хо-ро-шо.
Значит вы завязались на неопределённое поведение, которое может сломаться в любой момент. Дико осознавать, что фронтендер вынужден объяснять всё это сишнику.
Для справки, эквивалентный код на BetterC даже не скомпилируется:
extern(C) int main() {
int[4] arr = [0, 1, 2, 3];
return arr[5];
}Error: array index 5 is out of bounds `arr[0 .. 4]`
А даже если перенесёте получение индекса в рантайм, то получите падение, а не чтение чего попало из памяти:
extern(C) int main() {
int[4] arr = [0, 1, 2, 3];
int x = 5;
return arr[x];
}Assertion `array overflow' failed.Program terminated with signal: SIGSEGV
Хм. Написали код вы, а уязвимости у @aabzel? ;)
и язык разработки из мезозоя
Почему микроконтроллеры надо программировать именно на Си?
Какие есть варианты языков для программирования микроконтроллеров? Теоретически подойдет любой компилируемый язык программирования: Assembler, Cи, С++, Rust, Pascal
Однако выбирают обычно между Си и С++
1++Cи язык очень легко подается рефакторингу. Переименовывать функции, константы и переменные можно буквально утилитой sed. Прямо из командной строки внутри всего репозитория. При этом код по-прежднему будет собираться и проходить тесты.
2++У Си есть циклопическое Legacy. Нужный вам код можно взять из ядра Linux или Zephyr.
3++Программировать на Си проще чем программировать на Assembler или С++
4++Высокая скорость разработки. В сравнении с Assembler программирование на Си позволяет повысить производительность.
5++Это компилированный язык. Значит он будет исполняться быстрее чем интерпретированный язык.
6++Есть указатели.
7++Есть слово volatile
8++У компилятора GCC очень много ключей для гибкой настройки различных видов предупреждений на тот или иной синтаксис и семантику.
9++Вендоры микроконтроллеров дают MCAL именно на Си. Это сотни человеко-лет готовой работы. Поэтому чтобы сэкономить время и использовать их код надо тоже продолжать писать на Си.
10++Существует бесплатный компилятор GCC
11++Язык Си простой как ножик. Одни только функции и переменные. Прост в освоении. Тут не будет виртуальных деструкторов, делегатов, шаблонов и прочего. Код выглядит как математические формулы, которые и так все видели в школе.
12++Достоинство языка Си в том, что он старый 50+ лет и поэтому появились очень зрелые компиляторы. В частности в GCC появилось много опций для выявления UB.
Чего не хватает?
1--перегрузки функций. Хотя с этой задачей нормально справляются макросы препроцессора.
2--знаковых типов данных произвольной разрядности int13_t int7_t. Но этого и так нигде нет.
Итоги
Си- это идеальный язык для программирования микроконтроллеров. Компромисс между эффективностью и простотой.
кстати, разработали компилятор Fli-C, который помогает управлять безопасной работой памяти https://www.opennet.ru/opennews/art.shtml?num=62241
и язык разработки из мезозоя
Я вам больше скажу.
Мы ещё GNU make скрипты сами пишем для сборки Си кода!
По нашим временам проще натравить любую LLM и пусть проставляет каменты!
По нашим временам проще натравить любую LLM и пусть проставляет каменты!
То, что мы сейчас прочитали - это именно то, что нужно для решения всей проблемы.
Предлагаю Вам, Евгений, @gev до конца месяца составить, эту утилиту на LLM и написать тут на habr пояснительную записку про неё.
Чтобы уже в ближайшее время можно было автоматически проставлять корректные комментарии // end of xxx(...) после закрывающихся фигурных скобок во всем *.c файле новым, простым способом.
Погуглите Codemium/Windsurf, Cline, Zed AI, Cursor и еще с пучок подобных платных и бесплатных инструменов. И вам откроется море возможностей. Например, заменить в коде использование функциональных forEarch(), map(), filter() на циклы for с перечичлением по элементам коллекций или по индексу ели это еще удобнее. Пишите в свободной форме на любом человеческом языке задание в чатик прям в IDE своей, и идиете пить кофе, чай, через 15 минут полчаса смотрите дифы и ревьювите.
У Вас в организации есть обязательное требование подписывать закрывающиеся фигурные скобки?
Пишу на языке, где такое является частью синтаксиса. И да, у нас соблюдается такое требование:
function format_snils (
p_snils in number
) return varchar2 deterministic
as
begin
if p_snils is null then
return null;
end if;
return regexp_replace(lpad(p_snils, 11, '0'), '^(\d{3})(\d{3})(\d{3})(\d{2})$', '\1-\2-\3 \4');
end format_snils;
Стилистический-Анализатор: Проверка Наличия Комментария в Конце Фигурной Скобки