В принципе вопрос в заголовке темы.
Применительно к микроконтроллерам конечно, что плохого когда программа не сегментирует память, всё чётко распределено и даже есть ещё запас.
На забугорном сайте в качестве проблемы сегментирования памяти предлагают почаще перезагружаться, может всё таки тщательнее планировать ресурсы?
Проблемы глобальных переменных две - “замусоривание” глобального пространства имён (в C++ решается в общем то решается неймспейсами) и создание явной зависимости - если имя глобальной переменной надо поменять или ей надо переехать в другое какое то место придётся искать её упоминания по всему коду.
Если в проекте эти вещи не представляют проблемы, то и и смысла придерживаться этого хорошего правила нет.
1 лайк
А как это относится к программированию МК, где зачастую один раз запрограммированный алгоритм больше не будет изменяться? Да и объём кода можно обычно окинуть взглядом на одном экране?
не так давно в теме про часики с погодой была ссылка на проект, глянул я его, там 100500 файлов с расширением ino по 3 тысячи строк в каждом, ТС мозг выносил, дескать погодный ресурс забанили откуда данные брать, как на яндекс погоду переделать, то-есть бывает по разному, но в основном всё прогнозируемо конечно
На форуме красной нитью через многие обсуждения проходит мысль что МК надо выбирать под задачу, а не задачу впихивать в имеющийся МК. Большие красивые проекты делают всё же на большом железе, а у МК остаётся роль упрощеных переферийных устройств, у которых большие, многофайловые программы редкость.
Вопрос о сферических переменных в вакууме
- идиотский
- срачегенный.
Что плохого в молотке? Или в goto? Или в delay? Что вообще плохого в любом инструменте, если не вдаваться в то, как именно его предполагается использовать?
4 лайка
Вы всерьез думаете, что один экран текста компилируется в 512 кбайт кода?
А по поводу вопроса:
В глобальных переменных нет ничего плохого.
Плохое возникает лишь там, где глобальными переменными пытаются заменить другие разновидности переменных.
Тогда плохое - в нерациональном использовании памяти. Обычно - памяти программиста. Но в некоторых случаях - и памяти МК.
Если вспомнить, что для МК пишутся не только конечные проекты, но и пакеты поддержки - ситуация немного меняется. Пакет Ардуино для ЕСП32 - это же ведь тоже “код для МК”, хотя в нем десятки тысяч файлов.
Вот в таких-то проектах и встает во весь рост вопрос правильного проектирования кода и организации данных - глобальных и локальных.
А что касается проектов на одну страничку - там и обсуждать нечего, хоть на ФЛ-прог пишите 
Я говорил про конечные устройства. К той же нане тоже куча файлов в пакете поддержки но в конечное устройство мы прошиваем прошивку в которой от всех этих пакетов нет ничего в листинге программы. Блиньк десяток строчек кода.