Комментарии 84
А зачем вы там работаете?
Может у меня симпатия к продукту, который разрабатывает организация.
Не об одном месте речь же
Видишь ли, Дмитрий. Я в трёх компаниях работал с внутр. стандартом к коду.
И везде внутренний стандарт отличался. Причем по всем пунктам. Кардинально.
И каждый раз были абсурдные пункты там. Вот я их просуммировал и написал этот пост.
1—
...
5--
...
13 --
Код также оформляете?)
Хмм, мой 10-летний опыт работы в embedded говорит о том, что довольно часто на программистов скидывают какой-то проект, и люди изолированно его пилят. Вообще почти никогда никому не интересно, что там внутри под капотом. Очень такое любят в совдепо-подобных компаниях на 50 человек (Я в таких бывало когда-то давно работал)
В этом на самом деле есть огромный, жирный плюс. Когда делаешь изолированно свой проект - к тебе не приходят всякие "умники" с очень "нужными" советами. Есть только ты, и задача которая либо делает то что нужно, либо нет. И ты волен выбирать как организовать свой рабочий процесс, без всяких эффективных менеджеров, аналитиков, созвонов "с командой" по 3 часа, и прочей шелухи.
Но здесь есть большой минус для начинающих программистов. Научить как надо, некому.
Да. Работа программистом-микроконтроллеров в российских военных НИИ хороша тем, что начальство, как правило, тебе не мешает.
Там начальство это в прошлом схемотехники, конструкторы, чертёжники, кто угодно но только не программисты и оно понимает, что ничего в Си-программировании не понимает и просто предпочитает не мешать программистам-микроконтроллеров работать.
Или зачастую начальство программистов микроконтроллеров просто считает, что погружаться в подробности технической реализации схемотехники или программы прошивки продукта компании - это ну просто ниже их достоинства... Да, господа, именно так.
Поэтому в 5ти случаев из 7ми никто не будет говорить тебе что-то под руку и стоять над душой. Никто не будет шипеть над ухом. Никто не будет критиковать твой микроконтроллерный системный код. Никто его даже смотреть не станет.
Один минус. Зарплаты там низкие.
Если представить себе начальника совсем уж старой школы (лет 60+), который:
не хочет изучать то, что не знает (проще запретить использовать "лишний" функционал)
когда-то давно наступил на какие-то грабли (с тем же make или какой-нибудь несовместимостью в math.h) и нашёл обходное решение, которое теперь требует чтобы все его использовали
привык печатать исходники программ и изучать их с бумаги (отсюда требование писать название файла в первом комментарии)
соблюдать максимально строгие требования органов безопасности к сертификации кода (отсюда запрет использовать сторонние опенсорсные зависимости)
привык читать определённым образом отформатированный код ещё в те времена, когда автоматических инструментов для форматирования не было, и не хочет (не видит смысла) переучиваться на стиль, который они умеют поддерживать
...
и в целом привык работать скорее по гос.заказам нежели в стартапе
то никакого удивления эти правила не вызовут.
Единственная верная реакция в этой ситуации - "голосовать ногами".
После школы21 эти все пункты просто детский сад.
Показывали мне давно на Реддите такую схему. У классов-микросервисов где-то в середине среди комментариев - такая строчка: //[150 пробелов]&$--
Так вот: по этой строке скрипт CD определяет IP и credentials какой отладочной базы данных подставить при деплое. Догадываетесь зачем там 150 пробелов? Чтобы не было лишних вопросов. И главное: если этот комментарий отсутствует или неправильно парсится, то подключается - та-дам! боевой прод.
И при этом коде его единственный разработчик, успешно убедивший начальство, что он один во всём мире может разрабатывать эти сервисы, а если их доверить кому-то ещё, то сразу всё упадёт.
Выглядит так, что имеете дело с военной приёмкой.
Запрет 3rdparty - чтоб левых уязвимостей не занесли (как-то так мне когда-то аргументировали).
Странные требования к форматированию - чтоб исходники в папочке хранить, и формат не отличался от тех что с 80х годов хранятся.
Если я правильно понимаю, то ГОСТ Р 51904-2002 "Программное обеспечение встроенных систем. Общие требования к разработке и документированию" таки предусматривает, что исходный код может быть напечатан на бумаге (в отдельных случаях), отсюда и требования к шапкам определенной длины и т.п.
Там же в п. 8.3.4 "Просмотры и анализы исходного кода" и про гарантии того, что он не содержит неописанных функций, "нежелательных" операторов и структур и иную "точность и непротиворечивость".
По логике стандартизаторов, отход от установленного форматирования это как если чертежник начертил деталь розовым фломастером и размеры бы не везде написал - типа и так по линейке измерить можно, я ведь точно начертил.
Если я правильно понимаю, то ГОСТ Р 51904-2002 "Программное обеспечение встроенных систем. Общие требования к разработке и документированию" таки предусматривает, что исходный код может быть напечатан на бумаге (в отдельных случаях), отсюда и требования к шапкам определенной длины и т.п.
Текстовую портянку для печати сорцов можно составить при помощи Unix консольных утилит и скриптом добавить в эти логи для печати имена файлов, даты и баннеры конца файла.
Проблема в том что 60%...80% российских программистов-микроконтроллеров (даже возрастом 40+) не умеют пользоваться скриптами (никакими), так как из GUI-IDE никогда не вылазили.
Текстовую портянку для печати сорцов можно составить при помощи Unix консольных утилит и скриптом добавить в эти логи для печати имена файлов, даты и баннеры конца файла.
Речь ведь шла про шапки над функциями (4), а не только про начало/конец файла. Вы недооцениваете упоротость бюрократов. Они могут сверить исходники с распечаткой и увидеть несоответствие, и никого не будет интересовать что компилятор комментарии игнорирует.
Оффтоп конечно, но мне как-то раз проект нормативного акта так перед публикацией завернули - в текстовом файле в системе электронного документооборота 2 подписанта из 8 стояли не в том порядке, как в оригинале документа (требования как они должны были располагаться не было).
14. Использование кода сторонних библиотек запрещено! Никакого FreeRTOS, CMSIS, FatFs, HAL от официального производителя микроконтроллера! Любое Third Party запрещено!
Если имеете дело с медиками, военными или иными важными сферами, то запрет вполне оправдан - в том же кубе такая лапша и говнокод, что даже чатгпт лучше напишет. В той же libopencm3 баги я лично ловил... В остальном - типичное вахтерство.
13. Настройки компоновщика хранить прямо в папке с проектом. И так для каждого проекта с одним и тем же микроконтроллером. Получается дублирование конфигов для компоновщика.
А лучше делать лапшу инклудов, когда 9000 чипов на 100500 проектов, и понеслось - громадный write-only скрпт сборки, и не менее нечитаемый .ld-файл, где чёрт ногу сломит... Еще лучше тянуть откуда-то его - в одном проекте поменяли файл без предупреждения - легла вся сборка, и сиди разбирайся. Имхо, как раз красиво класть законченый файл под каждый контроллер в каждый проект - пофиг на дублирование, эра дискет прошла. С массовыми правками неудобно, но они настолько редки, что принимать их во внимание смыла не имеет.
15. Все аргументы функций должны быть перечислены "в столбик".
Когда их много, больше 5-7, то правило абсолютно верное, ибо эта строка даже в 4к монитор не всегда влезает :)
Остальное какая-то лютая дичь.
как раз красиво класть законченный файл под каждый контроллер в каждый проект - пофиг на дублирование
Надо чтобы в репозитории была папка для каждого микроконтроллера с которым происходит работа (или семейства). Там и хранить настройки компоновщика.
В этом случае несколько сборок смогут унаследовать один и тот же файл настройки компоновщика.
Исправления в одном месте раскатятся сразу на все нужные проекты.
Код надо строить иерархично.
Когда их много, больше 5-7, то правило абсолютно верное, ибо эта строка даже в 4к монитор не всегда влезает :)
Дело в том что clang-format не может принудительно расставить в столбик все аргументы везде. clang-format это делает только если не помещается в разрешенную ширину строку.
Остальное какая-то лютая дичь.
Обычно этот внутренний стандарт так составлен, что можно похерить абсолютно любой коммит.
Причину можно придумать всегда,так как надуманных правил просто немерено.
А утилиты авто-контроля, разумеется, нет в помине.
Вот и появляется фактор субъективности. Не нравится коллега (более способный конкурент), давай хейтить его коммиты, пока тот не уволится.
Красота!
для real time обычное дело, чем сложнее система тем больше требований, если активно работает 30-50 человек над проектом, неизбежно будут разные стили, как-то надо причесывать все это, главное чтобы max читабельно было, иначе совместную работу трудно вести, самый приятный код, который приходилось видеть был burroughs mcp много лет назад
Да, но надо меру знать. 20-50 требований ещё норм, но 400+ это перебор.
Либо писать свой внутренний компанейский анализатор для указания, где и что нарушается.
Держать в уме 463 требования к оформлению исходников это издёвка.
400+ перебор ...
нет такого не видел, типа зашкаливает, видел много другого, например когда алгоритмы отдельно документируют, или один важный модуль две разные группы дублируют независимо, да и зачем столько, типа воображения не хватает :)
На самом деле это даже здорово придумывать всё новые и новые требования к code style. Так можно аргументировать раздувание фронта работ начальству, что тебе и коллегам гарантирована оплачиваемая работа на обозримую перспективу. Можно годами как пиявка высасывать из компании зарплату за то, что с меньшими требованиями к code style можно сделать максимум за 2-3 месяца.
Начальство все понимает и одобряет.
можно сделать максимум за 2-3 месяца
Но не нужно.
Начальство все понимает и одобряет.
Особенно смешно потом смотреть как эти же менеджеры компании на совещаниях слёзно жалуются, что якобы очень долго и медленно тянется разработка.
Изменения вступают в силу только спустя месяц и более. А код ревьюверы, бедолаги, устают получать зарплату за инспекцию программ.
Мне как-то достался проект ( java), который нужно было немного допилить под изменившиеся требования. В нем идентификаторы были написаны на иврите, но латиницей (все равно, что написать русское слово "счетчик" как "schetchik"). Конечно, не зная иврита понять, что означают эти идентификаторы можно было только из контекста. Но это оказалось мелочью. Я долго не мог понять, откуда считываются параметры конфигурации при запуске. Оказалось, что конфиги были в комментариях в самих исходниках. Т.е.при запуске скомпилированной программы, нужно было тут же рядышком держать и исходники. Иначе, программа ругалась на то, что нет файлов конфигурации. Т.е. программа при запуске парсила свои же исходники и вычитывала из комментариев свою же конфигурацию. Какая-то извращенная сволочь это придумала.
Я плюнул на эти извраты и переписал считывание конфигурации из обычного текстовика, а не из собственного же исходника. С именами переменных я уже заморачиваться не стал и оставил as is.
А вы о каких-то стилях оформления кода толкуете :)))
Это какой-то новый уровень опенсорса - программа не только должна быть собрана из исходников, но и будет работать только со своими исходниками :)
"идентификаторы были написаны на иврите, но латиницей" Если названия переменных должны соотноситься с сущностями из словаря бизнес-логики, то тогда использование слов/терминов естественного языка совершенно оправдано, поскольку замена такой терминологии на англицизмы, во-первых, разрывает связь с устойчивой терминологией, что ведёт к сложностям в будущих попытках соотнести текст кода с описанием, и, во-вторых, иногда невозможна, в силу отсутствия (или редкости) прямых аналогов на английском языке. У нас в системе названия переменных/объектов БД/имена классов/имена файлов и т.п., как правило - именно ивритские слова, написанные латиницей (естественно)...
Вот хотелось бы пояснений от минусатора - это связано именно с ивритом, или, всё-таки есть возражения по существу? Хотя, пофиг, конечно...
Иврит тут не причем. Просто надо уважать соглашения, принятые большинством. Программу будут читать другие люди и, возможно, не владеющие языком на котором говорит автор оригинала. Я думаю, слово "counter" поймет куда больше людей чем слово "счетчик". И, главное, "counter" не вызовет раздражения у большинства. Если идентификатор соответствует тому, для чего он был введен (т.е. это действительно означает "счетчик", а не, скажем, "дата предыдущей операции"), то это похвально. Тем более, это же так просто - не выделываться.
Если что - минусил не я )))
Программа, которую, вероятно, будут читать люди, не владеющие ивритом, скорее всего, предназначена не для внутреннего израильского рынка, и, словарь бизнес-логики в этом случае должен соответствовать языку рынка для которого она предназначена. Я же написал, в каких случаях и для каких целей используются термины (слова) естественного языка - зачем перегибать палку со словом "counter"? Особенно с учётом того, что такие обобщенные имена тоже много смысла в программу не добавляют (чего "counter", зачем "counter"? 🙂 То есть, докопаться можно до столба). Я, например, знаю чётко, что в нашей системе означают словосочетания "дох ханая" или "икуль метальтелин" - и если по-русски я ещё смогу объяснить, что это такое, то существует ли такие, похожие по смыслу, выражения на английском, я даже ломать голову себе не буду - ибо нет смысла переводить эти вещи сначала на английский, а спустя десять лет ломать голову, что же это тогда подразумевалось... Поэтому, если здесь кто-то и выделывается, то это не я. Вообще, по-хорошему, словарь терминов, используемых для присвоения различных имён, должен быть частью дизайна системы и входить в перечень согласованных документов, но кто же об этом задумывается...
Так-то у меня был случай, когда при отладке с Brother'овским API получил Exception с текстом на китайском языке... Ну, Гугл сказал, что это null reference...
Писать на транслите это признак Junior программистов.
Дело в том что Junior плохо знает английский язык и поэтому пишет транслитом в комментариях и в компанейских чатах: (павершел, бутлодэр, сериальник, KAН, ватчдог, юзать, инлайн, хидер, дифайн, тула).
Junior глубоко убежден, что транслит в его исполнении - это самый правильный вариант транслита!
идентификаторы были написаны на иврите, но латиницей
Если писать на английском, то могут получаться пересечения с keywords, что реально бесит. Поэтому часто пишу названия переменных на немецком :)
Вспомнился анекдот про обезьян, у которых так принято.
В принципе большинство правил правильные.
Остальные, подозреваю, взяты из другой организации или придуманы автором чтобы разогреть тему.
Битовые поля, юнионы и перечисления стараюсь не использовать. И это потому что что они мешают отладке. Вообще все языковые конструкции что мешают отладке идут побоку.
Отладка важнее удобства и всякого синтаксического сахара.
Попадись мне автор в сотрудники я бы ему еще правил накидал.
Например, запретил бы писать несколько операторов в одну строку (потому что неудобно ставить брекпоинты). Все if тоже запретил бы писать без скобок (про той же причине). Запретил бы макросы с вычислениями (потому что отладчик не заходит в макросы и там нельзя проставить брекпоинт). Запретил бы тернарные операторы (опять из-за брекпоинтов ). Запретил бы большие буквы в переменных (потому что так принято в уважаемых сторонних проектах ). Заголовки функций, да должны быть по шаблону. (потому что память подводит, а что делает функция надо быстро вспомнить, а нормальные редакторы шапку формирую автоматом).
Да, комментарии везде ставлю такие //, это, во-первых, чтобы не лазить мышкой в конец текстового блока чтобы написать */ , а во-вторых комментарии типа // лучше выделяются в тексте при отладке, где может быть не виден конец комментария из-за узкого окна.
Но сам я конечно не сильно все это соблюдаю, обычно все это рефакторится постфактум.
Главное правило - рефакторить сорсы при малейшем подозрении на неудобства восприятия и отладки.
Тут недавно столкнулся с сорсами от Infineon. Там во всех условиях в конструкциях if сначала стоит константа, а потом переменная. Досталось видимо с той эпохи динозавров, когда == могли спутать с = . Но раздражает дико. Не поленился и в их либах везде исправил, потому что эти сорсы предстояло отлаживать. А в процессе отладки ничего не должно раздражать.
И это потому что что они мешают отладке.
Вы что, код только через пошаговую GDB отладку только отлаживаете что-ли?
Про технологии отладки тут. Но там, конечо, не все технологии.
Вот вам 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!
Странно, что ваш пресловутый бот не вспомнил про самый эффективный способ отладки прошивок: UART-CLI
Досталось видимо с той эпохи динозавров, когда == могли спутать с =
Динозавров понимаю - кода много, лапки короткие, мозг маленький;) А современные обезьяны не путают?
Битовые поля, юнионы и перечисления стараюсь не использовать. И это потому что что они мешают отладке.
Как оно может помешать отладке? О_о
У вас какой то культ DDD ;) Код отлаживается раз (а то и меньше), а читается часто. имхо лучше сразу писать так чтобы легче читалось.
Перечисления требуют введения нового типа. Новый тип тогда должен быть объявлен по всему простанству исходников в том числе и в сторонних, если с этим перечислением обращаться туда. Надо править кучу хидеров. Т.е. появление нового перечисления вызовет каскад рефакторнга гораздо большего чем введение просто целочисленной переменной. Ну и зачем лишний рефакторинг только потому что кто-то там когда-то сделал кучу ошибок при назначении констант? Может он в notepad-е программировал.
Битовые поля вызыват постоянную головную боль с пониманием точной позиции где они стоят. Ну и зачем еще лишняя боль? Да, в компактных протоколах битовые поля применяют. Но все меньше есть потребности в компактных протоколах.
Ну и зачем лишний рефакторинг только потому что кто-то там когда-то сделал кучу ошибок при назначении констант?
Именно затем. Ну, если базовый код написан плохо, его все равно когда то придется переписывать. Даже если это затронет 100500 хидеров.
Но как enum мешает при отладке я все равно не понял.
я тоже
Ну такие вещи даже ChatGPT знает:
Почему тип enum в языке C неудобен при отладке?
Тип
enumв языке C может быть неудобен при отладке по следующим причинам:
Отображение значений: При отладке компиляторы и отладчики часто отображают значения перечислений как целые числа, а не как имена констант. Это делает сложным быстрое понимание текущего значения переменной типа
enum, поскольку нужно помнить соответствие между числовым значением и его символическим именем.Отсутствие строгой типизации: В языке C типы
enumфактически являются целыми числами. Это значит, что переменной типаenumможно присвоить любое значение, которое подходит по размеру, даже если оно не соответствует ни одному из значений в перечислении. Это может привести к ошибкам, которые сложно отловить, особенно если вы не подозреваете, что переменной может быть присвоено "неправильное" значение.Сложность трассировки значений: Если в программе используется множество значений
enum, а переменные этого типа изменяются в разных частях кода, отладка может стать затруднительной из-за необходимости постоянного отслеживания, какие значения и где используются.Нет явной поддержки в некоторых отладчиках: Некоторые отладчики имеют ограниченную поддержку типов
enum, что может привести к необходимости вручную проверять соответствие числового значения и его текстового представления.Эти факторы делают использование
enumв C менее удобным в процессе отладки по сравнению с языками, где перечисления являются более строгими типами, как, например, в C++ или C#.
Вспоминаю цитату своего начальника схемотехника
7—Не нужны нам программисты-микроконтроллеров! Бот ChatGPT сам составит нам *.hex файл с прошивкой!
Вот за что мне нравится чатик - в любой момент можно налить произвольное количество воды :)
gdb умеет в enum, например
https://gist.github.com/gahr/2fba83db4d524bc0a39538e9fc7ecb91
За 5 лет, возможно, этот глюк с signed-unsigned починили
И что делать когда не работает и надо отлаживаться а там в одной строке цепочка из 5 функций ?
в одной строке цепочка из 5 функций ?
И они друг друга рекурсивно вызывают, а некоторые из них ещё и лямбды ;)
Универсальный совет: делайте хорошо, а плохо не делайте. Не благодарите :)
Я-то хорошо делаю и хотел вас научить делать хорошо. Я к тому что 5 функций могут вполне хорошо читаться, и очень молодежно смотреться, а в отладке п***ц. Так что критерий читаемости не достаточен.
Универсальный совет: делайте хорошо, а плохо не делайте.
У меня отец раньше маленько по другому говорил:
Делай хорошо. Плохо оно само получится
Запретил бы большие буквы в переменных (потому что так принято в уважаемых сторонних проектах
Ну вот это зря, camel word читаемость очень сильно повышает, а вреда никакого.
Желательно придерживаться какого то одного стиля. А то когда местами camel, местами snake, местами транслит, местами english, не очень повышает читабельность.
Думаю на это влияет размер и тип шрифта принятый в редакторе автора исходников.
В давние времена исходники были маленькие, окна редактора узкие, а шрифты большие. И так появился CamelCase и до сих пор рулит в софте под PC. Потому что отрефакторить этот стиль в snake_case уже нет возможности.
А в современном embedded рулит snake_case. Шрифты меньше, окна больше. Экономить на длине имен нет смысла. При мелком шрифте snake_case гораздо читабельней.
Шрифты меньше у тех, у кого либо зрение очень хорошее, либо кто не жалеет себя и готов глаза напрягать (с перспективой зрение посадить). У меня вот за 35 лет написания кода размер шрифта почти не изменился, как был достаточно крупный ещё в DOS, так и до сих пор крупный (size=24, это практически полноэкранное окно терминала/vi 100x28). Очень удобно. Пока не попадается код, который кто-то с мелким шрифтом писал под 150 символов в строку.
Пока не попадается код, который кто-то с мелким шрифтом писал под 150 символов в строку.
В редкаторах экран довольно динамический. Его отъедают со всех сторон вспомогательные панели. Но так обычный экран у меня это где-то 50 на 200 символов. Максимум 80 на 300.
И подозреваю что таким он стал не потому что я так захотел, а потому что это такой экран авторов большинства сторонних сорсов кторые я использую. Они в соотвествии с таким экраном делают средний размер своих функций и файлов.
Это сильно зависит от используемого языка.
Например, если писать HTML, то там может быть абсолютно любой уровень вложенности тегов (т.е. размер отступа), и текст действительно может "уехать" вправо и на 100 символов. Но в языках программирования, а не разметки, это уже является не нормой, а красным флагом: вероятным признаком того, что код переусложнён и нуждается в рефакторинге (причём это происходит уже где-то на 4-5 уровне отступов, т.е. при отступе всего в 40 символов даже при использовании стандартной ширины табов).
Аналогично, в разных языках приняты разные соглашения по именованию. Например в Go нормой являются максимально сокращённые идентификаторы (абсолютное большинство до 7 символов, почти все из них скорее 1-4 символа, и только в виде исключения изредка можно встретить и под 50, где это реально необходимо), а в Java наоборот, предпочитают более длинные - очевидно, что длина идентификатора может значительно увеличить среднюю длину строки не увеличивая при этом формальную сложность кода. Хотя к читабельности слишком длинных имён есть вопросики, конечно… ;-)
Поэтому когда строка кода конкретно на Go не влазит в 100 символов - это снова красный флаг, потому что с хорошим кодом и по объективным причинам такое происходит крайне редко.
Дело вкуса. Это пока в тексте не появляются названия с символами il1 на стыках слов. Правильный шрифт не спасает. Snake же читается вообще всегда и в любую погоду даже краем глаза без проблем.
В принципе большинство правил правильные.
Наш код(справа) приведен в соответствие внутреyнему сode-slyle(слева)
В принципе большинство правил правильные.
Айда тогда к нам в контору...
Существует ли утилита для проверки в С-коде того, что порядок объявления функций соответствует порядку определения функций?
В принципе большинство правил правильные.
В принципе большинство правил правильные.
Проблема еще и в том, что как правило при приведении работающего кода к внутреннему стандарту внешнего вида кода работающий код, как правило, перестает работать.
Я пишу это потому, что это в очередной раз произошло сегодня.
Если нужна овца, спроси на ферме Онара у пастуха
Misra вы тоже не признаете?
Почти все эти правила видел и в довольно крупных капиталистических корпорациях. Про битовые поля есть и в Мисре (рекомендует использовать либо битовые поля либо логические сдвиг, но не смешивать .. поскольку перенос кода с little-endian на big-endian процессор добавит головной боли). Насчет // end of file в конце - в разных редакторах кода/компиляторах могут быть проблемы с EOF и если последняя строчка кода у вас };EOF то опять будет много головной боли (кажется и в Мисре об этом говорится).
Автору стоит почитать Мисру от корки до корки, половина притензий отпадет сама собой.
Некоторые вполне имеют/имели смысл.
11,12 - раньше бывало по почте присылали сразу много исходников в одной простыне. Сейчас странное требование, все давно умеют файлы слать
21 - не надо постоянно помнить все глобалы. Хотя это можно решить и указанием этого в их названии
26 - когда есть много вложенных уровней - очень удобно указывать, к какому уровню скобка. Точнее - удобно потом разбираться. Тем более что в С скобка универсальна и порой как в LISP просто непонятно, где там в этой пачке заканчивается for, а где if. Пришёл сам к этому со временем.
Некоторые вполне имеют/имели смысл.
А как насчет
17. Порядок объявления функций должен совпадать с порядком определения функций.
?
Существует ли утилита для проверки в коде C того, что порядок объявления функций соответствует порядку определения функций?
В опциях компилятора GCC нет флагов для предупреждения о таком “нарушении”. Understand (scitools), CppCheck такого тоже не показывают.
Вот у меня h файл. Там 50+ функций объявлено. Есть у него *.с файл там эти 50+ функций определены.
Зачем делать одинаковый порядок объявления определения ? Компилятор и так соберёт всё корректно.
Это глупая трата времени сортировать их.
Все аргументы функций должны быть перечислены "в столбик".
А что не так с этим правилом? У нас ещё и обязательный префикс p_ для каждого аргумента (даже линтер самописный есть). А вот со следующим кодейстайлом сложнее:
int foo(
int p_arg1
,int p_arg2
,int p_bar
);
Порядок объявления функций должен совпадать с порядком определения функций. Просто лишнее правило, чтобы время больше потратить.
Аналогично, довольно строго придерживаемся этого правила.
А что не так с этим правилом?
"Гениальность" этого требования в том, что его невозможно выставить автоматически утилитой clang-format. Кто-то как будто специально выдумал это аутистское форматирование кода в столбик, чтобы саботировать разработку ПО во всей организации. Другого объяснения, тут придумать, простите, просто нереально....
У нас в конторе таких абсурдных требований хватает (вишенкой на торте - доведённый до абсурда формализм при их применении). Но кое за чтотвступлюсь. Часть перечисленного - ЕМНП это MISRA. А куда без неё в критичных системах?
Например, вроде именно мисра запрещает switch с диапазонами значений (case a … b:)
Пояснять комментарием закрытие блока кода - очень удобно! Когда имеешь кучу вложенных конструкций - запутаться легче лёгкого. У нас пояснять закрытие блока кода требуется только если он не умещается на экран, для функций - всегда.
Значителтную часть этих требований я в итоге упихнул в Perl-скрипт, который не просто детектирует отклонения, но по возможности их исправляет, генерируя исправленный файл (эдакий эрзац-бьютифаер). Потом в режиме сравнения можно согласиться с его правками, можно не согласиться.
Но в целом - согласен с автором. У разработчика и так есть чем голову забивать, а если вылизывание формальных требований 1) занимает больше времени, чем целевая задача, 2) противоречит заявленным целям (читаемость и поддерживаемомть кода)- то это МАРАЗМ.
А если от программистов и инженеров требуется ТОЧНОЕ СЛЕДОВАНИЕ СВЯЩЕННОМУ ШАБЛОНУ - то вместо них лучше нанять водителей трамвая.
Далее, про 3rd-part. В критических системах не может быть кода, который ты не контролируешь. Точка.
HAL? Ха, посмотрите, вроде STM - уважаемая фирма, но такой кал, как ихний хал - поискать ещё. Часть драйверов обращается к регистрам напрямую (прямо по адресам), часть - через файл определения регистров, косячная работа функции - в порядке вещей. И так чуть больше чем везде. Любая работа со стороней библиотекой начинается с её исправления, в итоге бывает проще написать свою. Ощущение, что иногда их выкладывают даже не запустив - собоалась - и ладно.
Нельзя Просто Так Пойти и Купить Овцу (или Потёмкинская Деревня в Коде)