@@NRelectronics Вы уже не в первый раз делаете акцент на аккуратность написания кода и это радует. Первый раз столкнулся с этим в Ваших начальных уроках по Си и стал вводить эти знания в свою практику. Жаль, но многие, кто выкладывает свои уроки по языкам, не говорят об этом вообще ничего.
Стараюсь приводить всё к порядку и дисциплине. Кто то помогает, часто советуют. Вот тут один подписчик посоветовал посмотреть на NASA C code Style. Оказалось что я 95% уже показал)
Много видел разного кода для встраиваемых систем и его оформление - это просто беда. Я пишу в разных средах, где-то есть форматтеры, где-то нет, поэтому для себя я один раз настроил утилиту форматирования кода AStyle и чужой код пропускаю через неё. Очень рекомендую для ускорения чтения разношерстного кода. IAR IDE и прочие имеют возможность запуска сторонней утилиты для текущего файла в редакторе. Пользуюсь этим для оформления кода при большом его количестве. Вообще, это очень большая тема и стоит почитать книжки, где объясняется почему именно лучше писать так или эдак, например, Совершенный код. Я в своё время прочитал и начал по-другому оформлять свой код.
@@NRelectronics Да. К примеру, оттуда есть такой совет по поводу организации порядка при объявлении переменных. Не многие понимают, что если упорядочивать переменные при объявлении по мере усложнения типа, то искать их при прочтении гораздо проще, т.к. ты ищешь не только по имени, но и по типу. Обычно простые типы идут сверху (bool, byte, short, int, ...), сложные уже ниже (указатели, строки, структуры и т.д.). Казалось бы простой совет - упорядочи переменные по типу, но об этом не задумываешься, если ты самоучка. И там много таких советов по мелочам. И - да, к Keil'у можно приделать AStyle, но там есть одна неприятная мелочь - я пока не нашёл удобного места расположения скрипта форматирования. Это зависит от организации дерева проектов.
@@NRelectronics мой большой комментарий пропал, писать заново лень. Кому интересно разберутся с AStyle самостоятельно. Это не панацея, но с ним гораздо удобнее читать отформатированные исходники сторонних библиотек. Пользоваться AStyle не всегда хорошая идея, к примеру, если код библиотеки сильно переусложнён. К сожалению, код для встраиваемых систем всё ещё сильно специфичен, чтобы можно было пользоваться инструментами из мира прикладного ПО. Оформление комментариев - это ещё одна отдельная тема, связанная с самодокументированием кода. Программист должен стараться вырабатывать в себе чувство прекрасного. Хотя бы для того, чтобы не было стыдно перед коллегами, если им придётся разгребать созданное тобой.
в этом отношении Go прекрасен более чем: в нем стиль является частью языка! а по поводу фигурных скобок - известный холивар. я, например, предпочитаю открывающую скобку ставить в конце строки.
вроде есть плагины в кайле или эклипсе для стандартизации кода. Жмешь кнопку, он вставляет заготовку для функции, которое просто заполняешь. На выходе получается текстовый файлик, как в исходниках библиотек от stm.
В современных и приличных языках инструмент форматирования кода встроен в поставку языка (Go, Rust), все приличные редакторы кода поддерживают автоформатирование перед сохранением. Но C/C++ - это старый язык, однако и для него есть море инструментов. Если коротко, clang-format + выбранный стиль. Умные люди придумали класс инструментов: linters. Они служат, в том числе, и для проверки соответствия кода определенному стилю. При наличии конфига с определением стиля и конфликта между людьми линтер всегда прав. Дальше добавляем запуск линтера в CI на каждый коммит и сразу видим все проблемы. Если что-то может делать робот, пусть это делает робот.
@@NRelectronics Есть линтеры под Си и Си++. Есть ли поддержка линтеров в этих доисторических и отставших от мира инструменатх - понятия не имею. А куб - это отдельное зло, которое приучает людей к ужасной структуре кода с самого начала.
У меня чего то структура действует только main.c.А в других файлах я не могу прописывать пишет ошибка.А typedef struct вообще не действует элементы структуры не могу вообще прописать в чем дело?
Коментарии в функциях нужны только в одном случае - когда функция является наглядным примером или конструктором для модификаций пользователя. В остальных случаях надобности заглядывать в функцию нет, достаточно имени и описания. Короткие переменные изначально зарезервированы для коротких циклов, которые могут целиком поместиться на экране (без прокрутки). Если однобуквенную переменную сделать глобальной - весёлости обеспечены.
принято делать вдумчиво и осмысленно. видел я анализ стат анализатором и все что он показывает пропускать нельзя. Нужно понимать что к чем и делать с пониманием.
Ну можно и не понимать, так пишут большинство программистов, и их код называют гавнокодом. Ничего там не сломаешь, мисра Си например чётко три группы и пошёл разбирать... Рассказываю: // - комментарий пришёл из плюсов в стандарт Си в С99, соответственно если поддерживать старый код то будет ошибка стат анализатора, и можно ещё, не понимая этого, знаком / закомментировать код следующей строки после строки комментария и код вообще ляжет... Поэтому рекомендуют уйти от этих потенциальных проблем и использовать классическое комментированиекомментирование /* */.
@@NRelectronics Сломать комментарием программный код - вполне обычная грабля любителей сахара. Там после 100500 вложенности дифлайнов мозг уже отказывает, и подобные ошибки вполне реальны. Кстати, мне встречалась либа с программной защитой от вандализма. Можно использовать как есть, но изменить просто невозможно. Там сахар раскрывался до управляющих символов, и имел замыкания в разных файлах. Половина кода на макросах, половина на внешних скомпилированных библиотеках, простого кода очень мало, зато файлов более 15к. Часть файлов собиралась по прямому пути, минуя общий каталог сборки. Отчего либа приобретала признаки бессмертия. Либу писал настоящий японец, отчего информативность немногочисленных комментариев стремится к нулю. Самое странное - она работает!!! И никто не знает как, и почему.
Не согласен с нежелательностью размещения комментария справа - комментарий в той-же строке делает информативным листинг поиска без необходимости скакать по коду.
Спасибо большое за ваш труд!
Вам спасибо.
Спасибо огромное!
Для меня визуальное оформление - пунктик:)
Спасибо)
На самом деле все важно, и начинается с мелочей, которые часто бросают...
Приятно встретить ещё кого-то с таким же пунктиком в голове. ))
Тоже люблю, чтобы выглядел код красиво.
по мне красиво - значит порядок! значит легче читается и сложнее допустить как опечатку так и ошибку.
@@NRelectronics Вы уже не в первый раз делаете акцент на аккуратность написания кода и это радует. Первый раз столкнулся с этим в Ваших начальных уроках по Си и стал вводить эти знания в свою практику.
Жаль, но многие, кто выкладывает свои уроки по языкам, не говорят об этом вообще ничего.
Стараюсь приводить всё к порядку и дисциплине. Кто то помогает, часто советуют. Вот тут один подписчик посоветовал посмотреть на NASA C code Style. Оказалось что я 95% уже показал)
Есть еще linux kernel style guide, barr group style guide, nasa style guide.
По комментариям можно сделать отдельное видео про doxygen
Особенно понравилось NASA style guide!)))
@@NRelectronics ну правильно он называется NASA. C Style Guide. Но мне лень была смотреть его название. Просто помню, что есть такой документ
качнул его сейчас, рассмешила сразу перевернутая страница вверх ногами, ща посмотрим что в космосе используют))
@@NRelectronics ну это же космос. Где верх, где низ - поди разбери))
Много видел разного кода для встраиваемых систем и его оформление - это просто беда. Я пишу в разных средах, где-то есть форматтеры, где-то нет, поэтому для себя я один раз настроил утилиту форматирования кода AStyle и чужой код пропускаю через неё. Очень рекомендую для ускорения чтения разношерстного кода. IAR IDE и прочие имеют возможность запуска сторонней утилиты для текущего файла в редакторе. Пользуюсь этим для оформления кода при большом его количестве.
Вообще, это очень большая тема и стоит почитать книжки, где объясняется почему именно лучше писать так или эдак, например, Совершенный код. Я в своё время прочитал и начал по-другому оформлять свой код.
Совершённый код Макконела кажется?
@@NRelectronics Да. К примеру, оттуда есть такой совет по поводу организации порядка при объявлении переменных. Не многие понимают, что если упорядочивать переменные при объявлении по мере усложнения типа, то искать их при прочтении гораздо проще, т.к. ты ищешь не только по имени, но и по типу. Обычно простые типы идут сверху (bool, byte, short, int, ...), сложные уже ниже (указатели, строки, структуры и т.д.).
Казалось бы простой совет - упорядочи переменные по типу, но об этом не задумываешься, если ты самоучка. И там много таких советов по мелочам.
И - да, к Keil'у можно приделать AStyle, но там есть одна неприятная мелочь - я пока не нашёл удобного места расположения скрипта форматирования. Это зависит от организации дерева проектов.
Какой ваш любимый ide для встраиваемых систем?
Упорядочение по типу это хороший совет, благодарю!)
Надо и мне попробовать AStyle ваш к кейлу прикрутить.
@@NRelectronics мой большой комментарий пропал, писать заново лень. Кому интересно разберутся с AStyle самостоятельно. Это не панацея, но с ним гораздо удобнее читать отформатированные исходники сторонних библиотек. Пользоваться AStyle не всегда хорошая идея, к примеру, если код библиотеки сильно переусложнён. К сожалению, код для встраиваемых систем всё ещё сильно специфичен, чтобы можно было пользоваться инструментами из мира прикладного ПО.
Оформление комментариев - это ещё одна отдельная тема, связанная с самодокументированием кода. Программист должен стараться вырабатывать в себе чувство прекрасного. Хотя бы для того, чтобы не было стыдно перед коллегами, если им придётся разгребать созданное тобой.
Плавно перешли на средний уровень языка си! Отлично! 👍👍👍
Спасибо!
Что за такой средний уровень такой?)
в этом отношении Go прекрасен более чем: в нем стиль является частью языка! а по поводу фигурных скобок - известный холивар. я, например, предпочитаю открывающую скобку ставить в конце строки.
Фигурные скобки вопрос действительно холиварный. Я думаю мой вариант наиболее читабельный.
@@NRelectronics дело привычки. я так и не смог. мне читабельней
if (...) {
} else {
}
@@NRelectronics самое главное, что в Go именно мой вариант - не пришлось перепривыкать после крестов.
дело привычки ;)
хорошо что вам Go зашел, жалко, что, для встраиваемых системы альтернативы С/С++ нет.
Спасибо
Пожалуйста
Это всё и так, как бы очевидно. ;)
Хотя некоторые так пишут код, что ничего не понятно.
У нас некоторые мидлы так напишут что хрен поймёшь... Тут интересное конечно дело))
@@NRelectronics Оооо, это да. Пишут на отеб... , как то заработало и ладно.
Как говориться:
Херяк херяк и в продакшн ;)
Эт верно!)))
вроде есть плагины в кайле или эклипсе для стандартизации кода. Жмешь кнопку, он вставляет заготовку для функции, которое просто заполняешь. На выходе получается текстовый файлик, как в исходниках библиотек от stm.
А напомните название плагинов в кейле?
В современных и приличных языках инструмент форматирования кода встроен в поставку языка (Go, Rust), все приличные редакторы кода поддерживают автоформатирование перед сохранением.
Но C/C++ - это старый язык, однако и для него есть море инструментов. Если коротко, clang-format + выбранный стиль.
Умные люди придумали класс инструментов: linters. Они служат, в том числе, и для проверки соответствия кода определенному стилю. При наличии конфига с определением стиля и конфликта между людьми линтер всегда прав.
Дальше добавляем запуск линтера в CI на каждый коммит и сразу видим все проблемы.
Если что-то может делать робот, пусть это делает робот.
Есть ли линтеры на Си или С++ под Кейл иди STM32CubeIDE?
clangformat довольно багованый, им тяжело пользоваться
@@NRelectronics Есть линтеры под Си и Си++. Есть ли поддержка линтеров в этих доисторических и отставших от мира инструменатх - понятия не имею. А куб - это отдельное зло, которое приучает людей к ужасной структуре кода с самого начала.
тогда какие инструменты по вашему мнению современные? критикуете, предлагайте лучшее ;)
У меня чего то структура действует только main.c.А в других файлах я не могу прописывать пишет ошибка.А typedef struct вообще не действует элементы структуры не могу вообще прописать в чем дело?
Стандарт языка не работает в чем дело?
@@NRelectronics Пишу struct ставлю указатель работает а вот ставлю typedef struct не работает.Да но работает в других файлах
Коментарии в функциях нужны только в одном случае - когда функция является наглядным примером или конструктором для модификаций пользователя. В остальных случаях надобности заглядывать в функцию нет, достаточно имени и описания.
Короткие переменные изначально зарезервированы для коротких циклов, которые могут целиком поместиться на экране (без прокрутки).
Если однобуквенную переменную сделать глобальной - весёлости обеспечены.
С однобуквенными согласен, что там когда-то имелось ввиду...
принято делать вдумчиво и осмысленно. видел я анализ стат анализатором и все что он показывает пропускать нельзя. Нужно понимать что к чем и делать с пониманием.
Ну можно и не понимать, так пишут большинство программистов, и их код называют гавнокодом. Ничего там не сломаешь, мисра Си например чётко три группы и пошёл разбирать...
Рассказываю:
// - комментарий пришёл из плюсов в стандарт Си в С99, соответственно если поддерживать старый код то будет ошибка стат анализатора, и можно ещё, не понимая этого, знаком / закомментировать код следующей строки после строки комментария и код вообще ляжет...
Поэтому рекомендуют уйти от этих потенциальных проблем и использовать классическое комментированиекомментирование /* */.
@@NRelectronics Сломать комментарием программный код - вполне обычная грабля любителей сахара. Там после 100500 вложенности дифлайнов мозг уже отказывает, и подобные ошибки вполне реальны.
Кстати, мне встречалась либа с программной защитой от вандализма. Можно использовать как есть, но изменить просто невозможно. Там сахар раскрывался до управляющих символов, и имел замыкания в разных файлах. Половина кода на макросах, половина на внешних скомпилированных библиотеках, простого кода очень мало, зато файлов более 15к. Часть файлов собиралась по прямому пути, минуя общий каталог сборки. Отчего либа приобретала признаки бессмертия. Либу писал настоящий японец, отчего информативность немногочисленных комментариев стремится к нулю. Самое странное - она работает!!! И никто не знает как, и почему.
Как работает действительно непонятно))
Не согласен с нежелательностью размещения комментария справа - комментарий в той-же строке делает информативным листинг поиска без необходимости скакать по коду.
Согласен. Просто если код правильнл написан то и комментарии не обязательны.
Автор мало рекламы, давай каждые полминуты ставь.
Шутите))) много тоже плохо)
Почему STM32 так внешне похожа на Eclipse?😂
STM32CubIDE основан на Atollic, а он в свою очередь на Eclipse)))
Подскажите какие тесты можно писать в контексте программирования железа?
Это хороший вопрос. Я отвечу полно несколько позже.
Unit тесты с использованием фреймворка Ceedling.
Не пора ли сделать курс по МК ???
Так есть ведь в соседних плейлистах ;)
@@NRelectronics с нуля???
Практически с нуля, с азов. Есть на регистрах, есть на хале...
Весь интернет завален этими курсами по МК с нуля, стоит ли?
А на заставке код на с++!
Молодцы, что заметили! Так и есть ;) С и С++ вместе всё равно повязаны...
Шикарное обьяснение
Благодарю!