не получиться универсального енума, глупости это. ИМХО. Тем более 8 или всего 4 значения. У каждой функции своя задача и свои возвращаемые значения.
мой черновик функции включения вращения антенны



офф


Слышали такое слово "говнокод"? Я думаю это порождение среди прогеров с/с++. Чужой код - всегда гавно. Каким бы он ни был. Либо он "не правильный", либо простой (можно услышать "фу, это аля си"), либо сложный для понимания читателя, либо он просто написан не в том стиле вплоть до того, что табы вместо пробелов, коменты на русском и т.п. Почему среди с/с++ - потому что одно и тоже можно написать 100500 способами, в отличие от других языков. С/С++ даёт творческий подход к решению задачи, и каждый поэт волен и считает что его поэма самая крутая. Язык не ограничивает пределы фантазий. Можно замутить такой оверинженеринг - шопипец, и при этом показать "смотри какой я крутой, как я могу?"

С таким подходом весь этот ресурс можно смело закрывать

Как вы передаёте код ошибки при вложенном вызове функций? Т.е. снизу на верх?

Ну конечно слышал, как и множество других мерзких слов. Тут вопрос в другом, позволить себе использовать это по отношению к другим, или нет?

Я понял, что вы имеете в виду Мне такие намёки тоже делали. Не прямыми словами. Когда я парировал, что это мой собственный стиль написания кода, человек, оскорбивший моё творчество, сватил жёсткий "батхёрт", и начал меня учить, что стили в коде это совершенно другое. В общем его задача была обругать, а не понять. И ему мои объяснения (хотя он мне и не начальник) были совершенно не нужны. К слову, его код постоянно подвергается справедливой (на мой взгляд) критике. Не ругане, а критике. Поэтому делаю вывод (не только по этому случаю), тот кто умеет делать дело, других ругать не станет. Максимум - аккуратно посоветует, как можно по-другому. Ну, а возомнивший себя профессионалом, будет изрыгать огонь налево и направо, при этом тащась от творений себе подобных

Я постарался дать обобщенные имена ошибкам. А как их интерпретировать, зависит от того, что ее выдало. По мне, 16 имен хватит за глаза.

Чаще я ошибки обрабатываю на месте и мне не нужно их передавать выше. Если нужно выше передать, то делаю общий енум кодов ошибок для отдельного куста.

Понятно! У вас тоже общий энум всё-таки не исключён
У меня была задача передавать коды ошибок "на верх" не только через иерархию функцию, но и устройств. Т.е., например, "железяка1"-"железяка2"-"комп".

Кстати, в данное время я решил выдавать результаты POST проверок бипами, пищалкой. Вот здесь уже использую перечисление ошибок конкретных устройств. Но это - другая сущность. Тоже 16-ти штук хватит за глаза. Может быть, и не только бипами ограничусь. Есть еще куда выдать.

Можно даже скомбинировать тип устройства и тип ошибки. Можно в один байт упаковать! "Остапа понесло."

Зачем вам передавать вверх?
Это как минимум выставляет дополнительные требования ко всем программным интерфейсам снизу вверх.
Сковывает рефакторинг. Увеличивает объем кодирования. Рассеивает точку внимания. Вызывает новые зависимости.
Т.е. в чем корневая причина?
Вас заставляют так делать, делаете библиотеки, корпоративный стандарт, используете IDE с ограниченными возможностями рефакторинга или что?

Я скажем везде где можно использую глобальные переменные и синглтоны. Очень удобно и лаконично получается.

Это многое объясняет


Наверно, есть смысл разделять ошибки на критические (аналог исключений в C++) и обычные, "рабочие".
Критические это те, которые не дают нормально работать приложению, т.е. аварийные.
Бипами, имхо, стоит афишировать критические ошибки (как на многих мат. платах компов).

А обычные ошибки лучше всего обрабатывать в коде именно в том месте, где производится вызов некой функции, которая возвращает ошибку.
В идеале нужно обрабатывать ВСЕ возможные ошибки, которые может возвратить некая функция. Т.е. предусмотреть поведение кода на ЛЮБУЮ ситуацию.
А передавать эту ошибку дальше не есть хорошо - это называется "скинуть ответственность", что всегда плохо заканчивается, зачастую создавая настолько редкие баги, что потом их ищут неделями.
Самый простой случай, когда код ошибки - возврат true/false, его очень просто обрабатывать (if ... else), читать и понимать такой код тоже очень просто.
Поэтому я тоже не понимаю таких вещей как "глобальные ошибки", универсальный набор ошибок и т. п. Сопровождать и отлаживать такой код - крайне неблагодарное занятие.
Как тут уже говорили комрады: универсальные решения - зло. Каждый кусок кода (модуль) должен делать именно то, что должен, и не более того.

Если же по необходимости используется сторонняя библиотека, то передавать возвращаемые ею ошибки дальше по коду - не есть хорошо. В последствии это принесет немало геморроя (см. выше).
Поэтому я лично предпочитаю "изолировать" внешние библиотеки от основного кода т. н. обертками (wrapper), в которых скрыта вся "черновая" работа по разгребанию результатов работы "неуклюже" написанной библиотеки.
А сам функционал (интерфейс) этой "обертки" урезать до минимума, оставляя самое необходимое и реальное важное.
При использовании исключений C++ можно "кидать" некоторые действительно важные исключения, но их обязательно нужно документировать, чтобы потом в коде правильно их "отлавливать".
Так же как аналог подобных критических исключений (как тут уже говорили выше) отлично годятся SVC вызовы. Их можно использовать на asm/c/c++.

Странная идея - добавить еще кода чтобы сделать код более понятным.
На самом деле эта изоляция - это наказание любителям плюсов вокруг которых все либы написаны на C.
Они вынуждены писать изоляцию чтобы скрестить ежа с ужом.

Это не идея, это нормальная практика в любой нормальной конторе - изолировать чужой не самый лучший код, пока он не врос в проект как раковая опухоль.
Богатые конторы вообще могут позволить себе заказать нужные либы с нужным функционалом и интерфейсом.


Плюсы тут ни при чем. Изолировать чужой говнокод можно даже на асм-е.
Можно даже изолировать чужой C++ говнокод на голом С, если в этом, конечно, есть особая нужда.
Однако, на плюсах (или другом аналогичном языке) грамотно проектировать проект намного проще и поэтому значительно удобнее в использовании и дальнейшем сопровождении кода.
Это вам скажет любой профи, который после ручной пилы освоил электро-лобзик, бензопилу и т.п. : ручную пилу он будет использовать лишь для мелких поделок и допилов.


В который раз прихожу к выводу, что вы не достаточно знакомы с предметом этого разговора и поэтому судите весьма поверхностно. Увы
Но это вполне нормально - чего-то не знать или не уметь. Ведь это поправимо: нынче очень много полезной развивающей литературы, было бы желание

За употребление слова "говнокод" я б вас забанил.
На самом деле так называют код в котором не могут разобраться, не знают контекст в котором он писался и для кого писался.
Таким образом перенося свою эмоцию на несчастный код.
А потом еще и изолируетесь от этого кода.
Вам похоже тяжело дается чужой код.
Дам вам совет. Не воюйте с кодом, а делайте его своим.
Начните с перехода на чистый С-и с урезанными синтаксисом, лучше даже MISRA-С. Пишите на языке на котором написана основная масса вашего кода.
Освойте рефакторинг, и увидите как у вас пропадут отрицательные эмоции к коду.

Был у нас embedded-проект один, где всякие флажки функций и прочая чепуха хранилась в глобальных переменных. С ростом проекта (порядка 50 тысяч строк) глаз обывателя настолько размыливается, что никакой сути из кода понять не возможно. А приложение еще и многопоточное (15 потоков, если память не изменяет). В итоге уже сколько времени рефакторим код, поскольку оно то ломается хрен знает где, то просто встроить какой-либо функционал становится нетривиальной задачей. Мне опыта "сопровождения" такого кода лично хватит на всю жизнь. Плюс ни о какой потокобезопасности речи нет. В общем, лично я пишу с минимизацией внешних связей, обрабатываю все ошибки, возвращаемые функциями в основном локально, то есть принимаю решение на месте по коду, что делать с результатом выполнения функций. Если прямого выхода нет - сообщаю внешним функциям, что что-то пошло не так. Рано или поздно такая цепочка заканчивается сама. А сопровождать такой код становится куда проще, и читаемость хорошая. Добавлять функционал или (что еще сложнее, порой) изменять текущий - в разы легче, чем держать в голове тысячу зависимостей от всех этих глобальных переменных.

Ну, тут вам тут виднее, но я же подобный код вообще не использую в своих проектах. Не стоит оно того.


"Эмоция" ... это что-то новенькое! Видать, вам волей-неволей приходится работать с подобным "несчастным кодом" ...
Печально слышать

Если вижу подобный код - нафик удаляю (с SHIFT+DELETE), ибо "хранить всякий хлам на балконе" у меня никак не получается ((


Вы явно не понимаете, почему приходится "изолировать" чужой код из сторонних библиотек, в т. ч. коммерческих.
А то получается некий "разговор глухого с немым".


Ну-ну


Так и хочется сказать: "аминь", но промолчу



зы. У меня ВЕСЬ код написан на С++, вот на нем и пишу ВЕСЬ проект, сторонние библиотеки "изолированы" соотв. классами-обертками.
А обратно в "джунгли" - "чистый С-и" и уже тем более c неким "урезанными синтаксисом" - не вернусь ни за какие коврижки!










Абсолютно согласен!

В свое время (много лет назад) я тоже "наелся" последствий подобной "глобализации" ...