Это у вас весьма маленькое приложение.
В каком редакторе вы его пишите и сколько человек занимается этим проектом?

В моем публичном проекте, где большинство переменных глобальные сейчас 393654 строки, около 20 разных задач, 1100 файлов.
Это только для одного из двух процессоров.
Я отлично в нем ориентируюсь. Мгновенно нахожу любые интересующие участки кода.
Могу легко модифицировать архитектуру приложения добавляя функциональность.
Практически любую ошибку могу найти в течении дня.

Дело не в наличии или отсутствии глобальных переменных, а в том как и кто их оформляет.

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


Xilinx SDK (Eclipse), проектом занимался сначала один, теперь 3 человека (но это не основная работа, а факультативная - вычистить беспорядок, так сказать).


Вот в этом как раз и проблема, что только Вы (возможно) в нем отлично ориентируетесь. Другое дело новичок, открыв Ваш проект, без Вашей помощи, разберется что там и к чему?
Я тоже в своих проектах разбираюсь быстро даже спустя год после последнего открытия. А также и мои коллеги, в случае моего долгого отсутствия, могут открыть и понять, где что подправить и где какую логику дописать.
Напомнило мне недавние размышления (это так, между делом, на работе) о незаменимости сотрудников. Напишет проект человек, напишет так, что только он в нем разбирается, накидает туда своих костылей, напрограммирует там методом "bug and fix", а потом попробуй уволь такого сотрудника. Выпытывали недавно тут одного такого, мол что за бардак в прошивке, ничего не ясно (хотели взяться за сопровождение), а он в ответ - "все константы и логика - у меня в голове и точка". А блок работает серийно, нужно внести изменения, а разработчик - ни в какую. Уволить - не могут - прошивки и исходники на личной флешке, да и сама логика работы - у него в голове лишь (хотя местный дядя в погонах может за это на ж*пу посадить при надобности, но это волокита и до этого еще можно заново все разработать).


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

История с глобальными переменными как-то мне напомнила историю с электронными мозгами тойоты...

Сообщение отредактировал Arlleex - May 3 2018, 19:30

Ну это уже бардак в организации рабочего процесса. Какие могут быть личные флешки? Git, svn решают проблему. А пушить в них - обязательное требование конторы.


Ну, а как пользователь за компом узнает, что произошла ошибка на нижнем уровне? И неисправимая ошибка.

В желании диагностировать любую, даже самую мелкую ошибку на нижнем уровне.

А как бы вы поступили, к примеру в следующем случае: пользователь жмёт кнопку запуска двигателя, а у двигателя отказал датчик (любой). Запуск без датчика невозможет в принципе, либо возможен, но в ограниченном режиме. Как передать эту "мелкую" ошибку от платы датчика к плате управления двигателем, а затем - наверх скаде?

Пишу для м\к на чистом С, для приложений на пк использовал паскаль, с++ (делфи, билдер). Исключения сам обрабатываю только в по для м\к. Функция возвращает всегда, или почти всегда, результат целого типа. Положительные значения это результат (символ, беззнаковое целое, указатель в массиве или булевое значение), отрицательные это код ошибки, ноль это ок и также может быть результат (булевое значение). Код ошибки передается наверх из вложенных функций по цепочке к обработчику исключений. Если необходимо возвратить строку, float или знаковое целое, передаю во входных параметрах указатель на переменную или на массив. Кодов ошибок немного, не более 10 или меньше, в разных задачах свои, не старался их стандартизировать, описываю их в определениях в заголовке проекта, для разных проектов коды ошибок свои. Всегда стараюсь использовать только стандартные библиотеки компилятора, самые простые функции.
Если использовать коды ошибок совместно, наверно следует договориться с коллегами, думаю лучше если ведущий группы сам определит коды ошибок для всех в группе.

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



Я же говорил, что чужой код всегда гэ. "говнокод" - это не ругательство, а синоним слова "чужой код" (хотя может "чужой код" - это и есть ругательство ))) . У AlexandrY код то ещё ни кто не глянул, но зато уже пошла критика, и только за то, что там глобальные переменные. А может его код с глобальными переменными гораздо понятнее и безопаснее, чем ваши ООП-эшные извраты.

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

если всё крутиться на ПК, то я на нижнем уровне генерирую сигнал с текстовым сообщением для юзера, а ГУИ поток этот сигнал обрабатывает слотом с выводом MessageBox и логированием.



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

Если заметите, то в 10 главных правилах MISRA ничего не говорится о глобальных переменных, а говорится только о необходимости сузить по возможности область видимости переменных.
А что такое у меня область видимости? Это весь проект!
Если б я писал библиотеки, то наверно завернул бы все переменные в static структуры.
А так мне глобальные переменные экономят кучу кода, соответственно код становится меньше и понятнее.

Код нельзя сделать понятнее закрыв другим кодом, он становится понятнее когда его становится меньше. С этим спорить не будете?

Барр когда критикует кучу глобальных переменных ссылается на то, что на них могут случайно воздействовать сторонние программисты.
Но у Тойоты тот код мог писать один программист, либо они проблему опасных взаимодействий решают организационно, а не средствами языка.
Ведь по сути весь OOП это в основном средство решения проблем коллективного взаимодействия.
В плане личной продуктивности ООП не дает ничего.

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

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

Подумайте, разве это не противоестественно не хотеть быть незаменимым?
По моему это желание не конфликтует ни с современной моралью ни с этикой.

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

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

Выдаете себя: ругаете то, чего, похоже, не понимаете

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

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

Я - о своем. Все уже придумано до нас.
https://ru.wikipedia.org/wiki/Errno.h
Для меня этого слишком много.

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

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

В некоторых моих текущих проектах он остался лишь только в одном месте:


Но в остальных уже заменен на такую конструкцию:

В принципе "static SomeApplication application" - единственный в проекте объект с квалификатором "static", а тут он еще и внутри main объявлен, что вообще напрочь закрывает к нему доступ из любого другого места даже в самом файле, где реализуется этот "main()".
Поэтому считаю такое решение пока что вполне допустимым.

Ага... сказочник..... Языком все горазды находить.
Хотя.... используете только глобальные переменные... а как же функции? все рабочие переменные в них - тоже глобальные??? а как же тогда многозадачность? для каждой из 20и задач своя копия всех функций со всеми переменными? А то может и функций нет, а только копипаст?
Пожалуй тогда поиск ошибки за день в таком коде выглядит менее сказочно... и становится понятным откуда такое количество строк...

Ну что, я как раз таким занимаюсь.
Тут надо отделить стандартные решения на PLC и решения на собственных контроллерах.
Приходилось проектировать и то и другое.
Буквально несколько дней назад в новом аэропорту около Мельбурна мужики взяли и никого не спросив переставили местами управляющие ящики с электрикой и PLC.
Ящики внешне похожи, но имеют разный состав модулей ввода-вывода.

Честно на такую ошибку я не рассчитывал. Ящики то были пронумерованы.
Так вот в PLC все переменные глобальные! Програма там содержала под два десятка программных модулей, более 500 глобальных переменных.
В то что можно назвать SCADA ( а точнее удаленный HMI) по EtherCAT не передавались в моем случае никакие коды ошибок.
PLC содержат глобальные переменные счетчиков ошибок и регистров ошибок. К ним имеют доступ все HMI в сети. Т.е. имеем вид связи поставщик-подписчик или как-то так.
Ошибок вылезло не одна, а куча.
Но мужики посмотрели в окне HMI состояния переменных разных ошибок (ну они были выведены в виде анимации) и довольно быстро сообразили в чем дело.

В собственных контроллерах у меня практически также. Моя, так назовем, SCADA на базе пакета FreeMaster читает из дивайса базу публикуемых глобальных! переменных.
И сама уже в зависимости от конфигурации HMI читает эти переменные прямо из памяти устройства. Т.е. опять коммуникация по принципу поставщик-подписчик.

Итог - все ошибки есть глобальные переменные. Да они могут кодироваться. А иногда я просто их реализую как строки содержащие текст описания ошибки.
Таким образом я давно уже не пишу функций передающих коды ошибок. Максимум мои функции отдают OK или ERROR.

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

Остаюсь при своём мнении: передавать коды ошибок наверх для меня удобно)
Кстати, можно сделать такой тип для ошибки


т.е. в простейшем варианте поле ok показывает была ли ошибка вообще, и если была, то можно указатель extparams привести к любому типу, расшифровывающему ошибку (variadic, string и т.п.). А можно сделать его 0, тогда это значит, что параметров нет.

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

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

Я лишь идею предложил, а реализацией не занимался. Вполне возможно, что не всё так гладко на первый взгляд. Зато - гибко. Можно к любому типу привести.