Пролог
В некоторых организациях, в которых программируют микроконтроллеры есть свой внутренний стандарт оформления Си-исходников (сорцов). Как правило там обычно есть разумные пункты. Однако в этом тексте я перечислил самые нелепые и абсурдные требования и рекомендации оформления сорцов, которые реально присутствуют в современных российских электронных организациях, где программируют микроконтроллеры.
Это требования категории, мягко говоря, "зачем?". Вот буквально несколько реальных примеров из жизни. Это просто диктатура абсурда, парад нелепости.
1. Запрет установки программ, запрет открытия диспетчера устройств, запрет открытия диспетчера задач, запрет прописывания переменной PATH на локальных PC. Всё только через пароль руководителя отдела.
2. Собирать код только мышкой из-под GUI-IDE (IAR или KEIL) и никаких там скриптов сборки (Make, CMake)! У нас зарплатный фонд такой, что мы можем нанять только студентов, а они умеют программировать только в IDE. Мышкой.
3. Строгие правила расставления отступов к коде и вообще искусственно выдуманное форматирование кода, которое даже опциями clang-format или GNU-indent выставить невозможно. Только ручное расставление отступов!
4. Строгие правила оформления шапки текста перед каждой функцией. Не дай бог поставишь лишний пробел!
5. Писать текстовые комментарии к каждой строчке Си-кода. Не важно, что по именам переменных и функций и так всё ясно.
6. Строгий запрет на использование битовых полей в языке программирования Си.
7. Строжайший запрет на использование объединений (union) в программах Си .
8. Строжайший запрет на использование перечислений (enum) в языке программирования Си.
9. Каждая конфигурационная константа должна иметь комментарий с "Valid values", в котором описано множество возможных значений данной константы. Перечисления (enum) же запрещены, поэтому надо как-то выкручиваться, через эти текстовые комментарии.
10. Запрет на использование стандартных типов данных из файлов <stdint.h> <stdbool.h> (bool, uint32_t, int8_t и проч.)
11. Первая строка файла должна содержать комментарий "start of file"
12. Предпоследняя строка исходного файла должна содержать комментарий
"//****end of file*******"
Как мне сказал автор требования: "Это чтобы посылать код сообщением в текстовом мессенджере и чтобы было понятно, где заканчивается файл". Как вам такая аргументация?
13. Настройки компоновщика хранить прямо в папке с проектом. И так для каждого проекта с одним и тем же микроконтроллером. Получается дублирование конфигов для компоновщика.
14. Использование кода сторонних библиотек запрещено! Никакого FreeRTOS, CMSIS, FatFs, HAL от официального производителя микроконтроллера! Любое Third Party запрещено!
15. Все аргументы функций должны быть перечислены "в столбик", везде и всегда! "Гениальность" этого требования в том, что его невозможно выставить автоматически утилитой clang-format. Кто-то как будто специально выдумал это аутистское форматирование кода в столбик, чтобы саботировать разработку ПО во всей организации. Другого объяснения, тут придумать, простите, но просто нереально....
16. Для всех объявлений глобальных функций в h-файле обязательно ключевое слово extern! Не важно, что и без extern код собирается и работает.
17. Порядок объявления функций должен совпадать с порядком определения функций. Просто лишнее правило, чтобы время больше потратить.
18. Все комментарии должны начинаться с //~ и никак иначе!
Мы выдумаем свой фирменный стиль для однострочных комментариев. Так мы продвигаем свой бренд.
19. Запрет на многострочные комментарии /**/
20. Строжайший запрет на использование функций из <math.h> [sin() cos() log10() fabs() и т. п.]!
21. Рядом с глобальными переменными писать комментарием: "Смотрите, это глобальные переменные!"
22. В верху си-файла писать название файла комментарием. Не важно, что это и так видно в файловой системе. А потом еще следить, чтобы всегда совпадало. Везде.
23. В конце каждой функции писать комментарий: "смотрите, это конец функции!" А то ведь по фигурной скобке не ясно...
24. Все статические функции прописывать в конце файла. А потом ещё вверху второй раз прописывать прототипы этих функций. Видимо, чтобы времени на работу больше потратить и увеличить вероятность рассинхронизировать имена переменных в прототипах и определениях.
Ничем не аргументированный стиль закрытия include guard
делать закрытие include guard не так:
#endif // INCLUDE_FILE_H
а вот эдак:
#endif // #ifndef INCLUDE_FILE_HВ конце каждого If писать комментарий: "смотрите это конец if". В конце каждого for писать комментарий: "смотрите это конец for". В конце каждого switch писать комментарий: "смотрите это конец switch". И тому подобное.
Требования к коду это хорошо, однако сами понимаете, что всё вышеперечисленное - просто требования ради требований. Больше похоже на цитаты туркменского президента, нежели на какой-то разумный стандарт разработки софтвера. Как говорят
Благими намерениями вымощена дорога в ад.
Думаю не надо пояснять, что такая мартышкина бюрократия лишь только тормозит достижение реального функционального результата по разработке system software. Как если бы отрыли тормозной парашют в самолёте на эшелоне.
При этом, добавлю, что в таких щепетильно "требовательных" организациях, как правило, не принято собирать проекты из скриптов, покрывать код модульными тестами, в прошивках нет NVRAM, в прошивках отсутствует UART-CLI для отладки функционала, нет и сервера сборки, никакого, даже в Jenkins, в прошивках нет загрузчика и многого того, что, по здравому смыслу вообще-то должно, быть сделано как раз в первую очередь... Понимаете?...
Порой всё это законотворчество выглядит, как соблюдать правила хирургической стерильности, в конюшне! Да.. Именно так... Чрезмерные требования к оформлению кода похоже на какую-то армейскую IT-муштру.
Итоги
Вот объясните мне, пожалуйста, в чем глубинный смысл упомянутых выше требований к коду?
Было бы нормально, если эти требования сопровождались бы короткой, ясной и прозрачной аргументацией для чего их так рьяно нагнетают. И чтобы были выставлены приоритеты какие требования более важные, а какие так...
Я лично абсолютно ничего не имею против списка требований к коду. Это даже здорово, что есть стабильная предсказуемая работа вокруг всего этого цирка.
На самом деле это даже здорово придумывать всё новые и новые требования к code style. Так можно аргументировать раздувание фронта работ начальству, что тебе и коллегам гарантирована оплачиваемая работа на обозримую перспективу. Можно годами как пиявка высасывать из компании зарплату за то, что с меньшими требованиями к code style можно сделать максимум за 2-3 месяца.
Я к тому, что требований можно выдумывать сколько душе удобно, но тогда должен быть либо:
1--консольная tool(a) для автоматической установки таких требований: а-ля clang-format
2--консольная tool(a) для автоматического поиска и выявления нарушений требований: а-ля cpp-check
Правда в том, что каждое требование к коду сдвигает срок сдачи программного проекта на 10-15%. Когда в организации, например, 463+ правила оформления Си-кода, то время разработки, как ни крути, увеличивается в 46 раз! Понимаете?
Как говорят:
Любой каприз за Ваш счёт...
Скажите мне, смог бы солдат Курчатов Игорь Васильевич сделать атомную бомбу с нуля за 4 года с такой вот мартыхиной бюрократией? Думаю ответ и так всем понятен...
Пишите в комментариях какие странные требования к оформлению исходников есть или были в вашей организации. Мне просто интересно можно ли придумать что-то ещё более абсурдное в разработке на Си, чем то, что я перечислил в этой заметке.
Ссылки
Комментарии (67)
ripandtear
21.08.2024 16:33+2Хмм, мой 10-летний опыт работы в embedded говорит о том, что довольно часто на программистов скидывают какой-то проект, и люди изолированно его пилят. Вообще почти никогда никому не интересно, что там внутри под капотом. Очень такое любят в совдепо-подобных компаниях на 50 человек (Я в таких бывало когда-то давно работал)
В этом на самом деле есть огромный, жирный плюс. Когда делаешь изолированно свой проект - к тебе не приходят всякие "умники" с очень "нужными" советами. Есть только ты, и задача которая либо делает то что нужно, либо нет. И ты волен выбирать как организовать свой рабочий процесс, без всяких эффективных менеджеров, аналитиков, созвонов "с командой" по 3 часа, и прочей шелухи.
Но здесь есть большой минус для начинающих программистов. Научить как надо, некому.
aabzel Автор
21.08.2024 16:33+2Да. Работа программистом-микроконтроллеров в российских военных НИИ хороша тем, что начальство, как правило, тебе не мешает.
Там начальство это в прошлом схемотехники, конструкторы, чертёжники, кто угодно но только не программисты и оно понимает, что ничего в Си-программировании не понимает и просто предпочитает не мешать программистам-микроконтроллеров работать.
Или зачастую начальство программистов микроконтроллеров просто считает, что погружаться в подробности технической реализации схемотехники или программы прошивки продукта компании - это ну просто ниже их достоинства... Да, господа, именно так.Поэтому в 5ти случаев из 7ми никто не будет говорить тебе что-то под руку и стоять над душой. Никто не будет шипеть над ухом. Никто не будет критиковать твой микроконтроллерный системный код. Никто его даже смотреть не станет.
Один минус. Зарплаты там низкие.
powerman
21.08.2024 16:33+6Если представить себе начальника совсем уж старой школы (лет 60+), который:
не хочет изучать то, что не знает (проще запретить использовать "лишний" функционал)
когда-то давно наступил на какие-то грабли (с тем же make или какой-нибудь несовместимостью в math.h) и нашёл обходное решение, которое теперь требует чтобы все его использовали
привык печатать исходники программ и изучать их с бумаги (отсюда требование писать название файла в первом комментарии)
соблюдать максимально строгие требования органов безопасности к сертификации кода (отсюда запрет использовать сторонние опенсорсные зависимости)
привык читать определённым образом отформатированный код ещё в те времена, когда автоматических инструментов для форматирования не было, и не хочет (не видит смысла) переучиваться на стиль, который они умеют поддерживать
...
и в целом привык работать скорее по гос.заказам нежели в стартапе
то никакого удивления эти правила не вызовут.
Единственная верная реакция в этой ситуации - "голосовать ногами".
olku
21.08.2024 16:33+3Печать названий файлов может быть требованием к архивированию или передаче куда либо на бумаге.
MountainGoat
21.08.2024 16:33+2Показывали мне давно на Реддите такую схему. У классов-микросервисов где-то в середине среди комментариев - такая строчка: //[150 пробелов]&$--
Так вот: по этой строке скрипт CD определяет IP и credentials какой отладочной базы данных подставить при деплое. Догадываетесь зачем там 150 пробелов? Чтобы не было лишних вопросов. И главное: если этот комментарий отсутствует или неправильно парсится, то подключается - та-дам! боевой прод.
И при этом коде его единственный разработчик, успешно убедивший начальство, что он один во всём мире может разрабатывать эти сервисы, а если их доверить кому-то ещё, то сразу всё упадёт.
dataerased
21.08.2024 16:33+3Выглядит так, что имеете дело с военной приёмкой.
Запрет 3rdparty - чтоб левых уязвимостей не занесли (как-то так мне когда-то аргументировали).
Странные требования к форматированию - чтоб исходники в папочке хранить, и формат не отличался от тех что с 80х годов хранятся.
Serpentine
21.08.2024 16:33+1Если я правильно понимаю, то ГОСТ Р 51904-2002 "Программное обеспечение встроенных систем. Общие требования к разработке и документированию" таки предусматривает, что исходный код может быть напечатан на бумаге (в отдельных случаях), отсюда и требования к шапкам определенной длины и т.п.
Там же в п. 8.3.4 "Просмотры и анализы исходного кода" и про гарантии того, что он не содержит неописанных функций, "нежелательных" операторов и структур и иную "точность и непротиворечивость".
По логике стандартизаторов, отход от установленного форматирования это как если чертежник начертил деталь розовым фломастером и размеры бы не везде написал - типа и так по линейке измерить можно, я ведь точно начертил.
aabzel Автор
21.08.2024 16:33+2Если я правильно понимаю, то ГОСТ Р 51904-2002 "Программное обеспечение встроенных систем. Общие требования к разработке и документированию" таки предусматривает, что исходный код может быть напечатан на бумаге (в отдельных случаях), отсюда и требования к шапкам определенной длины и т.п.
Текстовую портянку для печати сорцов можно составить при помощи Unix консольных утилит и скриптом добавить в эти логи для печати имена файлов, даты и баннеры конца файла.
Проблема в том что 60%...80% российских программистов-микроконтроллеров (даже возрастом 40+) не умеют пользоваться скриптами (никакими), так как из GUI-IDE никогда не вылазили.Serpentine
21.08.2024 16:33+2Текстовую портянку для печати сорцов можно составить при помощи Unix консольных утилит и скриптом добавить в эти логи для печати имена файлов, даты и баннеры конца файла.
Речь ведь шла про шапки над функциями (4), а не только про начало/конец файла. Вы недооцениваете упоротость бюрократов. Они могут сверить исходники с распечаткой и увидеть несоответствие, и никого не будет интересовать что компилятор комментарии игнорирует.
Оффтоп конечно, но мне как-то раз проект нормативного акта так перед публикацией завернули - в текстовом файле в системе электронного документооборота 2 подписанта из 8 стояли не в том порядке, как в оригинале документа (требования как они должны были располагаться не было).
kenomimi
21.08.2024 16:33+514. Использование кода сторонних библиотек запрещено! Никакого FreeRTOS, CMSIS, FatFs, HAL от официального производителя микроконтроллера! Любое Third Party запрещено!
Если имеете дело с медиками, военными или иными важными сферами, то запрет вполне оправдан - в том же кубе такая лапша и говнокод, что даже чатгпт лучше напишет. В той же libopencm3 баги я лично ловил... В остальном - типичное вахтерство.
13. Настройки компоновщика хранить прямо в папке с проектом. И так для каждого проекта с одним и тем же микроконтроллером. Получается дублирование конфигов для компоновщика.
А лучше делать лапшу инклудов, когда 9000 чипов на 100500 проектов, и понеслось - громадный write-only скрпт сборки, и не менее нечитаемый .ld-файл, где чёрт ногу сломит... Еще лучше тянуть откуда-то его - в одном проекте поменяли файл без предупреждения - легла вся сборка, и сиди разбирайся. Имхо, как раз красиво класть законченый файл под каждый контроллер в каждый проект - пофиг на дублирование, эра дискет прошла. С массовыми правками неудобно, но они настолько редки, что принимать их во внимание смыла не имеет.
15. Все аргументы функций должны быть перечислены "в столбик".
Когда их много, больше 5-7, то правило абсолютно верное, ибо эта строка даже в 4к монитор не всегда влезает :)
Остальное какая-то лютая дичь.
aabzel Автор
21.08.2024 16:33как раз красиво класть законченный файл под каждый контроллер в каждый проект - пофиг на дублирование
Надо чтобы в репозитории была папка для каждого микроконтроллера с которым происходит работа (или семейства). Там и хранить настройки компоновщика.
В этом случае несколько сборок смогут унаследовать один и тот же файл настройки компоновщика.
Исправления в одном месте раскатятся сразу на все нужные проекты.
Код надо строить иерархично.
aabzel Автор
21.08.2024 16:33Когда их много, больше 5-7, то правило абсолютно верное, ибо эта строка даже в 4к монитор не всегда влезает :)
Дело в том что clang-format не может принудительно расставить в столбик все аргументы везде. clang-format это делает только если не помещается в разрешенную ширину строку.
tmxx
21.08.2024 16:33Ну, то есть вы ссылаетесь на возможности инструмента.
Противоречие в вашей позиции вижу я...
aabzel Автор
21.08.2024 16:33Я к тому, что требований можно выдумывать сколько душе удобно, но тогда должен быть либо:
1--тула для автоматической установки таких требований: а-ля clang-format2--тула для автоматического поиска и выявления нарушений требований: а-ля cpp-check
victor_1212
21.08.2024 16:33для real time обычное дело, чем сложнее система тем больше требований, если активно работает 30-50 человек над проектом, неизбежно будут разные стили, как-то надо причесывать все это, главное чтобы max читабельно было, иначе совместную работу трудно вести, самый приятный код, который приходилось видеть был burroughs mcp много лет назад
aabzel Автор
21.08.2024 16:33Да, но надо меру знать. 20-50 требований ещё норм, но 400+ это перебор.
Либо писать свой внутренний компанейский анализатор для указания, где и что нарушается.
Держать в уме 463 требования к оформлению исходников это издёвка.victor_1212
21.08.2024 16:33+1400+ перебор ...
нет такого не видел, типа зашкаливает, видел много другого, например когда алгоритмы отдельно документируют, или один важный модуль две разные группы дублируют независимо, да и зачем столько, типа воображения не хватает :)
aabzel Автор
21.08.2024 16:33+1На самом деле это даже здорово придумывать всё новые и новые требования к code style. Так можно аргументировать раздувание фронта работ начальству, что тебе и коллегам гарантирована оплачиваемая работа на обозримую перспективу. Можно годами как пиявка высасывать из компании зарплату за то, что с меньшими требованиями к code style можно сделать максимум за 2-3 месяца.
randomsimplenumber
21.08.2024 16:33+1Начальство все понимает и одобряет.
можно сделать максимум за 2-3 месяца
Но не нужно.
atues
21.08.2024 16:33+6Мне как-то достался проект ( java), который нужно было немного допилить под изменившиеся требования. В нем идентификаторы были написаны на иврите, но латиницей (все равно, что написать русское слово "счетчик" как "schetchik"). Конечно, не зная иврита понять, что означают эти идентификаторы можно было только из контекста. Но это оказалось мелочью. Я долго не мог понять, откуда считываются параметры конфигурации при запуске. Оказалось, что конфиги были в комментариях в самих исходниках. Т.е.при запуске скомпилированной программы, нужно было тут же рядышком держать и исходники. Иначе, программа ругалась на то, что нет файлов конфигурации. Т.е. программа при запуске парсила свои же исходники и вычитывала из комментариев свою же конфигурацию. Какая-то извращенная сволочь это придумала.
Я плюнул на эти извраты и переписал считывание конфигурации из обычного текстовика, а не из собственного же исходника. С именами переменных я уже заморачиваться не стал и оставил as is.
А вы о каких-то стилях оформления кода толкуете :)))
S_gray
21.08.2024 16:33"идентификаторы были написаны на иврите, но латиницей" Если названия переменных должны соотноситься с сущностями из словаря бизнес-логики, то тогда использование слов/терминов естественного языка совершенно оправдано, поскольку замена такой терминологии на англицизмы, во-первых, разрывает связь с устойчивой терминологией, что ведёт к сложностям в будущих попытках соотнести текст кода с описанием, и, во-вторых, иногда невозможна, в силу отсутствия (или редкости) прямых аналогов на английском языке. У нас в системе названия переменных/объектов БД/имена классов/имена файлов и т.п., как правило - именно ивритские слова, написанные латиницей (естественно)...
S_gray
21.08.2024 16:33Вот хотелось бы пояснений от минусатора - это связано именно с ивритом, или, всё-таки есть возражения по существу? Хотя, пофиг, конечно...
atues
21.08.2024 16:33+1Иврит тут не причем. Просто надо уважать соглашения, принятые большинством. Программу будут читать другие люди и, возможно, не владеющие языком на котором говорит автор оригинала. Я думаю, слово "counter" поймет куда больше людей чем слово "счетчик". И, главное, "counter" не вызовет раздражения у большинства. Если идентификатор соответствует тому, для чего он был введен (т.е. это действительно означает "счетчик", а не, скажем, "дата предыдущей операции"), то это похвально. Тем более, это же так просто - не выделываться.
Если что - минусил не я )))
aabzel Автор
21.08.2024 16:33Писать на транслите это признак Junior программистов.
Дело в том что Junior плохо знает английский язык и поэтому пишет транслитом в комментариях и в компанейских чатах: (павершел, бутлодэр, сериальник, KAН, ватчдог, юзать, инлайн, хидер, дифайн, тула).
Junior глубоко убежден, что транслит в его исполнении - это самый правильный вариант транслита!
fiego
21.08.2024 16:33идентификаторы были написаны на иврите, но латиницей
Если писать на английском, то могут получаться пересечения с keywords, что реально бесит. Поэтому часто пишу названия переменных на немецком :)
Indemsys
21.08.2024 16:33+7В принципе большинство правил правильные.
Остальные, подозреваю, взяты из другой организации или придуманы автором чтобы разогреть тему.
Битовые поля, юнионы и перечисления стараюсь не использовать. И это потому что что они мешают отладке. Вообще все языковые конструкции что мешают отладке идут побоку.
Отладка важнее удобства и всякого синтаксического сахара.
Попадись мне автор в сотрудники я бы ему еще правил накидал.
Например, запретил бы писать несколько операторов в одну строку (потому что неудобно ставить брекпоинты). Все if тоже запретил бы писать без скобок (про той же причине). Запретил бы макросы с вычислениями (потому что отладчик не заходит в макросы и там нельзя проставить брекпоинт). Запретил бы тернарные операторы (опять из-за брекпоинтов ). Запретил бы большие буквы в переменных (потому что так принято в уважаемых сторонних проектах ). Заголовки функций, да должны быть по шаблону. (потому что память подводит, а что делает функция надо быстро вспомнить, а нормальные редакторы шапку формирую автоматом).
Да, комментарии везде ставлю такие //, это, во-первых, чтобы не лазить мышкой в конец текстового блока чтобы написать */ , а во-вторых комментарии типа // лучше выделяются в тексте при отладке, где может быть не виден конец комментария из-за узкого окна.Но сам я конечно не сильно все это соблюдаю, обычно все это рефакторится постфактум.
Главное правило - рефакторить сорсы при малейшем подозрении на неудобства восприятия и отладки.Тут недавно столкнулся с сорсами от Infineon. Там во всех условиях в конструкциях if сначала стоит константа, а потом переменная. Досталось видимо с той эпохи динозавров, когда == могли спутать с = . Но раздражает дико. Не поленился и в их либах везде исправил, потому что эти сорсы предстояло отлаживать. А в процессе отладки ничего не должно раздражать.
aabzel Автор
21.08.2024 16:33+3И это потому что что они мешают отладке.
Вы что, код только через пошаговую GDB отладку только отлаживаете что-ли?
Indemsys
21.08.2024 16:33+1Про технологии отладки тут. Но там, конечо, не все технологии.
aabzel Автор
21.08.2024 16:33Indemsys
21.08.2024 16:33+2Вот вам 31 способ отладки:
JTAG
SWD (Serial Wire Debug)
UART Debugging
SPI/I2C Debugging
GDB (GNU Debugger)
OpenOCD
Trace Debugging
printf Debugging
In-Circuit Emulator (ICE)
Logic Analyzer
Oscilloscope
Boundary Scan
Hardware Breakpoints
Software Breakpoints
Watchpoints
Memory Monitoring
Peripheral Registers Inspection
Firmware Logging
Event Tracing
Code Coverage Analysis
Static Code Analysis
Unit Testing
Integration Testing
Simulation Tools
Bootloader Debugging
Crash Dumps/Memory Dumps
Fuzz Testing
Fault Injection Testing
Power Analysis
Electromagnetic Interference (EMI) Testing
Hardware-in-the-Loop (HIL) Testing
Привет от ChatGPT!
randomsimplenumber
21.08.2024 16:33+5Досталось видимо с той эпохи динозавров, когда == могли спутать с =
Динозавров понимаю - кода много, лапки короткие, мозг маленький;) А современные обезьяны не путают?
Битовые поля, юнионы и перечисления стараюсь не использовать. И это потому что что они мешают отладке.
Как оно может помешать отладке? О_о
У вас какой то культ DDD ;) Код отлаживается раз (а то и меньше), а читается часто. имхо лучше сразу писать так чтобы легче читалось.
Indemsys
21.08.2024 16:33Перечисления требуют введения нового типа. Новый тип тогда должен быть объявлен по всему простанству исходников в том числе и в сторонних, если с этим перечислением обращаться туда. Надо править кучу хидеров. Т.е. появление нового перечисления вызовет каскад рефакторнга гораздо большего чем введение просто целочисленной переменной. Ну и зачем лишний рефакторинг только потому что кто-то там когда-то сделал кучу ошибок при назначении констант? Может он в notepad-е программировал.
Битовые поля вызыват постоянную головную боль с пониманием точной позиции где они стоят. Ну и зачем еще лишняя боль? Да, в компактных протоколах битовые поля применяют. Но все меньше есть потребности в компактных протоколах.randomsimplenumber
21.08.2024 16:33Ну и зачем лишний рефакторинг только потому что кто-то там когда-то сделал кучу ошибок при назначении констант?
Именно затем. Ну, если базовый код написан плохо, его все равно когда то придется переписывать. Даже если это затронет 100500 хидеров.
Но как enum мешает при отладке я все равно не понял.
Indemsys
21.08.2024 16:33Ну такие вещи даже ChatGPT знает:
Почему тип enum в языке C неудобен при отладке?
Тип
enumв языке C может быть неудобен при отладке по следующим причинам:Отображение значений: При отладке компиляторы и отладчики часто отображают значения перечислений как целые числа, а не как имена констант. Это делает сложным быстрое понимание текущего значения переменной типа
enum, поскольку нужно помнить соответствие между числовым значением и его символическим именем.Отсутствие строгой типизации: В языке C типы
enumфактически являются целыми числами. Это значит, что переменной типаenumможно присвоить любое значение, которое подходит по размеру, даже если оно не соответствует ни одному из значений в перечислении. Это может привести к ошибкам, которые сложно отловить, особенно если вы не подозреваете, что переменной может быть присвоено "неправильное" значение.Сложность трассировки значений: Если в программе используется множество значений
enum, а переменные этого типа изменяются в разных частях кода, отладка может стать затруднительной из-за необходимости постоянного отслеживания, какие значения и где используются.Нет явной поддержки в некоторых отладчиках: Некоторые отладчики имеют ограниченную поддержку типов
enum, что может привести к необходимости вручную проверять соответствие числового значения и его текстового представления.
Эти факторы делают использование
enumв C менее удобным в процессе отладки по сравнению с языками, где перечисления являются более строгими типами, как, например, в C++ или C#.aabzel Автор
21.08.2024 16:33Вспоминаю цитату своего начальника схемотехника
7—Не нужны нам программисты-микроконтроллеров! Бот ChatGPT сам составит нам *.hex файл с прошивкой!
randomsimplenumber
21.08.2024 16:33+1Вот за что мне нравится чатик - в любой момент можно налить произвольное количество воды :)
gdb умеет в enum, например
https://gist.github.com/gahr/2fba83db4d524bc0a39538e9fc7ecb91
За 5 лет, возможно, этот глюк с signed-unsigned починили
swame
21.08.2024 16:33+1И что делать когда не работает и надо отлаживаться а там в одной строке цепочка из 5 функций ?
randomsimplenumber
21.08.2024 16:33+1в одной строке цепочка из 5 функций ?
И они друг друга рекурсивно вызывают, а некоторые из них ещё и лямбды ;)
Универсальный совет: делайте хорошо, а плохо не делайте. Не благодарите :)
swame
21.08.2024 16:33Я-то хорошо делаю и хотел вас научить делать хорошо. Я к тому что 5 функций могут вполне хорошо читаться, и очень молодежно смотреться, а в отладке п***ц. Так что критерий читаемости не достаточен.
randomsimplenumber
21.08.2024 16:33+25 функций могут вполне хорошо читаться, и очень молодежно смотреться, а в отладке п***ц.
Ну, выпишите себе премию за победу над соломенным чучелом ;) Вы сами придумали какой то г-код и сами его раскритиковали. Да, 5 функций в 1 строку читать тоже невозможно. И зачем так писать? Экономия строк?
rukhi7
21.08.2024 16:33+1Универсальный совет: делайте хорошо, а плохо не делайте.
У меня отец раньше маленько по другому говорил:
Делай хорошо. Плохо оно само получится
aabzel Автор
21.08.2024 16:33Да. Есть такая поговорка.
Но она какая- то обречённая. Якобы ,какая разница хорошо делаешь или плохо. Плохо само получится .
Лучше говорить:" нормально делай, нормально будет."
Skipy
21.08.2024 16:33+2Запретил бы большие буквы в переменных (потому что так принято в уважаемых сторонних проектах
Ну вот это зря, camel word читаемость очень сильно повышает, а вреда никакого.
randomsimplenumber
21.08.2024 16:33Желательно придерживаться какого то одного стиля. А то когда местами camel, местами snake, местами транслит, местами english, не очень повышает читабельность.
Indemsys
21.08.2024 16:33+1Думаю на это влияет размер и тип шрифта принятый в редакторе автора исходников.
В давние времена исходники были маленькие, окна редактора узкие, а шрифты большие. И так появился CamelCase и до сих пор рулит в софте под PC. Потому что отрефакторить этот стиль в snake_case уже нет возможности.
А в современном embedded рулит snake_case. Шрифты меньше, окна больше. Экономить на длине имен нет смысла. При мелком шрифте snake_case гораздо читабельней.powerman
21.08.2024 16:33+1Шрифты меньше у тех, у кого либо зрение очень хорошее, либо кто не жалеет себя и готов глаза напрягать (с перспективой зрение посадить). У меня вот за 35 лет написания кода размер шрифта почти не изменился, как был достаточно крупный ещё в DOS, так и до сих пор крупный (size=24, это практически полноэкранное окно терминала/vi 100x28). Очень удобно. Пока не попадается код, который кто-то с мелким шрифтом писал под 150 символов в строку.
Indemsys
21.08.2024 16:33Пока не попадается код, который кто-то с мелким шрифтом писал под 150 символов в строку.
В редкаторах экран довольно динамический. Его отъедают со всех сторон вспомогательные панели. Но так обычный экран у меня это где-то 50 на 200 символов. Максимум 80 на 300.
И подозреваю что таким он стал не потому что я так захотел, а потому что это такой экран авторов большинства сторонних сорсов кторые я использую. Они в соотвествии с таким экраном делают средний размер своих функций и файлов.powerman
21.08.2024 16:33Это сильно зависит от используемого языка.
Например, если писать HTML, то там может быть абсолютно любой уровень вложенности тегов (т.е. размер отступа), и текст действительно может "уехать" вправо и на 100 символов. Но в языках программирования, а не разметки, это уже является не нормой, а красным флагом: вероятным признаком того, что код переусложнён и нуждается в рефакторинге (причём это происходит уже где-то на 4-5 уровне отступов, т.е. при отступе всего в 40 символов даже при использовании стандартной ширины табов).
Аналогично, в разных языках приняты разные соглашения по именованию. Например в Go нормой являются максимально сокращённые идентификаторы (абсолютное большинство до 7 символов, почти все из них скорее 1-4 символа, и только в виде исключения изредка можно встретить и под 50, где это реально необходимо), а в Java наоборот, предпочитают более длинные - очевидно, что длина идентификатора может значительно увеличить среднюю длину строки не увеличивая при этом формальную сложность кода. Хотя к читабельности слишком длинных имён есть вопросики, конечно… ;-)
Поэтому когда строка кода конкретно на Go не влазит в 100 символов - это снова красный флаг, потому что с хорошим кодом и по объективным причинам такое происходит крайне редко.
DrZlodberg
21.08.2024 16:33+1Дело вкуса. Это пока в тексте не появляются названия с символами il1 на стыках слов. Правильный шрифт не спасает. Snake же читается вообще всегда и в любую погоду даже краем глаза без проблем.
grand1987
21.08.2024 16:33Почти все эти правила видел и в довольно крупных капиталистических корпорациях. Про битовые поля есть и в Мисре (рекомендует использовать либо битовые поля либо логические сдвиг, но не смешивать .. поскольку перенос кода с little-endian на big-endian процессор добавит головной боли). Насчет // end of file в конце - в разных редакторах кода/компиляторах могут быть проблемы с EOF и если последняя строчка кода у вас };EOF то опять будет много головной боли (кажется и в Мисре об этом говорится).
Автору стоит почитать Мисру от корки до корки, половина притензий отпадет сама собой.
DrZlodberg
21.08.2024 16:33Некоторые вполне имеют/имели смысл.
11,12 - раньше бывало по почте присылали сразу много исходников в одной простыне. Сейчас странное требование, все давно умеют файлы слать
21 - не надо постоянно помнить все глобалы. Хотя это можно решить и указанием этого в их названии
26 - когда есть много вложенных уровней - очень удобно указывать, к какому уровню скобка. Точнее - удобно потом разбираться. Тем более что в С скобка универсальна и порой как в LISP просто непонятно, где там в этой пачке заканчивается for, а где if. Пришёл сам к этому со временем.
Tzimie
А зачем вы там работаете?
aabzel Автор
Может у меня симпатия к продукту, который разрабатывает организация.
qiper
Не об одном месте речь же
aabzel Автор
Видишь ли, Дмитрий. Я в трёх компаниях работал с внутр. стандартом к коду.
И везде внутренний стандарт отличался. Причем по всем пунктам. Кардинально.
И каждый раз были абсурдные пункты там. Вот я их просуммировал и написал этот пост.