[juvf 10]

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

мой черновик функции включения вращения антенны

 

/*
* -1 если нет связи с двигателем.
* -2 если двигатель уже вкл.
* -3 если есть превышение ветра или нет связи с анемометром при включении
* -4 если нет связи с датчиком вращения антенны
* -5 если открыт люк
* -6 если антенна заброкированна
*  1 включен двигатель 1
*  2 включен двигатель 2
*  0 выключены оба двигателя
*/

 

офф

Коллеги, маленькое лирическое отступление) Прошу не воспринимать, как офф......

 

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

 

[Forger 17]

Чужой код - всегда гавно

 

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

 

 

 

[haker_fox 60]

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

мой черновик функции включения вращения антенны

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

Слышали такое слово "говнокод"?

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

Чужой код - всегда гавно. Каким бы он ни был.

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

[ViKo 1]

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

[juvf 10]

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

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

 

[haker_fox 60]

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

Понятно! У вас тоже общий энум всё-таки не исключён :rolleyes:

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

[ViKo 1]

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

[ViKo 1]

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

[AlexandrY 3]

Понятно! У вас тоже общий энум всё-таки не исключён :rolleyes:

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

Зачем вам передавать вверх?

Это как минимум выставляет дополнительные требования ко всем программным интерфейсам снизу вверх.

Сковывает рефакторинг. Увеличивает объем кодирования. Рассеивает точку внимания. Вызывает новые зависимости.

Т.е. в чем корневая причина?

Вас заставляют так делать, делаете библиотеки, корпоративный стандарт, используете IDE с ограниченными возможностями рефакторинга или что?

 

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

 

[Forger 17]

... везде где можно использую глобальные переменные ...

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

 

Кстати, в данное время я решил выдавать результаты POST проверок бипами, пищалкой.

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

Критические это те, которые не дают нормально работать приложению, т.е. аварийные.

Бипами, имхо, стоит афишировать критические ошибки (как на многих мат. платах компов).

 

А обычные ошибки лучше всего обрабатывать в коде именно в том месте, где производится вызов некой функции, которая возвращает ошибку.

В идеале нужно обрабатывать ВСЕ возможные ошибки, которые может возвратить некая функция. Т.е. предусмотреть поведение кода на ЛЮБУЮ ситуацию.

А передавать эту ошибку дальше не есть хорошо - это называется "скинуть ответственность", что всегда плохо заканчивается, зачастую создавая настолько редкие баги, что потом их ищут неделями.

Самый простой случай, когда код ошибки - возврат true/false, его очень просто обрабатывать (if ... else), читать и понимать такой код тоже очень просто.

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

Как тут уже говорили комрады: универсальные решения - зло. Каждый кусок кода (модуль) должен делать именно то, что должен, и не более того.

 

Если же по необходимости используется сторонняя библиотека, то передавать возвращаемые ею ошибки дальше по коду - не есть хорошо. В последствии это принесет немало геморроя (см. выше).

Поэтому я лично предпочитаю "изолировать" внешние библиотеки от основного кода т. н. обертками (wrapper), в которых скрыта вся "черновая" работа по разгребанию результатов работы "неуклюже" написанной библиотеки.

А сам функционал (интерфейс) этой "обертки" урезать до минимума, оставляя самое необходимое и реальное важное.

При использовании исключений C++ можно "кидать" некоторые действительно важные исключения, но их обязательно нужно документировать, чтобы потом в коде правильно их "отлавливать".

Так же как аналог подобных критических исключений (как тут уже говорили выше) отлично годятся SVC вызовы. Их можно использовать на asm/c/c++.

[AlexandrY 3]

Поэтому я лично предпочитаю "изолировать" внешние библиотеки от основного кода т. н. обертками (wrapper), в которых скрыта вся "черновая" работа по разгребанию результатов работы "неуклюже" написанной библиотеки.

А сам функционал (интерфейс) этой "обертки" урезать до минимума, оставляя самое необходимое и реальное важное.

Странная идея - добавить еще кода чтобы сделать код более понятным.

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

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

[Forger 17]

Странная идея - добавить еще кода чтобы сделать код более понятным.

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

Богатые конторы вообще могут позволить себе заказать нужные либы с нужным функционалом и интерфейсом.

 

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

Плюсы тут ни при чем. Изолировать чужой говнокод можно даже на асм-е.

Можно даже изолировать чужой C++ говнокод на голом С, если в этом, конечно, есть особая нужда.

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

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

 

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

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

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

[AlexandrY 3]

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

...

Изолировать чужой говнокод можно даже на асм-е.

За употребление слова "говнокод" я б вас забанил.

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

Таким образом перенося свою эмоцию на несчастный код.

А потом еще и изолируетесь от этого кода.

Вам похоже тяжело дается чужой код. ;)

Дам вам совет. Не воюйте с кодом, а делайте его своим.

Начните с перехода на чистый С-и с урезанными синтаксисом, лучше даже MISRA-С. Пишите на языке на котором написана основная масса вашего кода.

Освойте рефакторинг, и увидите как у вас пропадут отрицательные эмоции к коду.

[Arlleex 131]

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

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

[Forger 17]

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

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

 

Таким образом перенося свою эмоцию на несчастный код.

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

Печально слышать :crying:

 

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

 

А потом еще и изолируетесь от этого кода.

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

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

 

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

Ну-ну :cranky:

 

Начните с перехода на чистый С-и с урезанными синтаксисом, лучше даже MISRA-С. Пишите на языке на котором написана основная масса вашего кода.

Освойте рефакторинг, и увидите как у вас пропадут отрицательные эмоции к коду.

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

 

 

 

зы. У меня ВЕСЬ код написан на С++, вот на нем и пишу ВЕСЬ проект, сторонние библиотеки "изолированы" соотв. классами-обертками.

А обратно в "джунгли" - "чистый С-и" и уже тем более c неким "урезанными синтаксисом" - не вернусь ни за какие коврижки!

 

 

 

 

 

 

 

 

 

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

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

 

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