Почему плохие глобальные переменные в однопоточном встроенном приложении
do i need to throw an exception or does the computer automatically throws one at runtime?
Вам нужно throw исключение самостоятельно и catch оно. например,
try {
//...
throw int();
}
catch(int i) { }
Или catch исключение, которое выдается вашим кодом.
try {
int *p = new int();
}
catch (std::bad_alloc e) {
cerr << e.what();
}
В вашем случае я не уверен, существует ли какое-либо стандартное исключение, предназначенное для делим на ноль. Если такого исключения нет, вы можете использовать
catch(...) { // catch 'any' exception
}
13 ответов
Это не так.
Две фундаментальные проблемы с глобальными переменными - это просто загромождение пространства имен и тот факт, что «никто» не «контролирует» их (таким образом, потенциальные коллизии и конфликты с несколькими потоками).
«Глобальность плоха», как и почти любая другая компьютерная программа, является руководством, а не жестким и быстрым правилом. Когда создаются такие «правила», лучше всего просто принять правило наизусть, чтобы понять обстоятельства и мотивы создания правила. Не принимайте их вслепую.
В вашем случае вы, похоже, поняли природу вашей системы и аргументы вокруг правила и решили, что в этом случае оно не применимо. Вы правы, это не так.
Так что, не беспокойтесь об этом.
Глобальные переменные необходимы в небольшом встроенном приложении, написанном на C. Например, вам нужно использовать глобальную переменную для передачи информации между подпрограммой обработки прерываний и другим модулем. Вот несколько советов, которые помогут вам эффективно использовать глобальные переменные во встроенных приложениях:
-
Различайте статические переменные и глобальные переменные. Статические переменные могут использоваться из всех функций в одном и том же C-файле. Они являются эквивалентом закрытых членов в классе C ++. В Си вы должны выполнять работу компилятора самостоятельно. Используйте ключевое слово static, чтобы избежать случайного использования переменной за пределами модуля и сделать ее видимой. Возможно, вы захотите добавить префикс к имени модуля.
-
Следуйте соглашению об именовании глобальных переменных (используется многими C-файлами). Сделайте ясно, что они глобальны.
-
Если вам нужно много глобальных переменных, рассмотрите возможность их объединения в структуру.
-
Используйте ключевое слово volatile, когда это необходимо. Это необходимо, если глобальная переменная изменена ISR.
Глобальные переменные не обязательно плохие, так же как макросы не обязательно плохие, а обогащенный уран не обязательно плохой. Пока вы принимаете осознанное решение о плюсах и минусах данного выбора дизайна, у вас все будет в порядке.
Некоторые из аргументов против глобальных переменных:
- Они нарушают хороший объектно-ориентированный дизайн
- Они делают ваш код трудным для юнит-тестирования, поскольку вы не можете тестировать отдельные блоки кода без установки всех глобальных переменных, которые код ожидает увидеть
- Они увеличивают сцепление в вашем коде: действия в одном блоке кода могут влиять на вещи в другом блоке кода непредсказуемым образом через общую глобальную переменную
Некоторые из аргументов для глобальных переменных:
- Они облегчают совместное использование одного ресурса между многие функции
- Они могут облегчить чтение кода
Если в вашем проекте глобальные переменные имеют смысл, и их можно использовать для упрощения чтения или поддержки вашего кода , не настраивая себя на случайные ошибки и проверяя головные боли, тогда непременно используйте их.
Я пишу много кода на C для встроенных микроконтроллеров и постоянно использую глобальные переменные. В такой жесткой системе глобальные переменные имеют смысл. Я знаю о потенциальных недостатках, но я проанализировал плюсы и минусы. минусы и я пишу свой код, чтобы защититься от основных ловушек.
Итог: нет жесткого и быстрого правила. Просто примите лучшее решение для вашего конкретного проекта или платформы, основываясь на лучшей информации, которую вы имеете.
Короткий ответ заключается в том, что глобальные переменные исторически были источником тонких ошибок. Но затем (надевая на меня функциональную голову программиста) все переменные были источниками тонких ошибок.
По сути, глобальная переменная означает, что вы не можете смотреть на кусок кода, используя значение переменной, и знать, что он собирается делать, не зная, что делал каждый другой фрагмент кода, устанавливающий значение этой переменной в прошлом.
Потому что это минимизирует сцепление. Ваша система может быть маленькой сейчас, но если вы продолжите работать, может оказаться, что это не так.
Вот хорошая статья, объясняющая причину Почему глобальные переменные плохие
Почему следует избегать глобальных переменных, когда они не нужны?
Нелокальность. Исходный код легче всего понять, когда область его отдельных элементов ограничена. Глобальные переменные могут быть прочитаны или изменены любой частью программы, что затрудняет их запоминание или рассуждение о каждом возможном использовании. Отсутствие контроля доступа или проверки ограничений - глобальная переменная может быть получена или установлена любой частью программы, и любые правила, касающиеся ее использования, могут быть легко нарушены или забыты.
Неявная связь - Программа со многими глобальными переменными часто имеет тесную связь между некоторыми из этих переменных и связь между переменными и функциями. Группировка связанных элементов в единые блоки обычно приводит к улучшению программ.
Проблемы с выделением памяти. В некоторых средах существуют схемы выделения памяти, которые усложняют распределение глобалов. Это особенно верно в языках, где «конструкторы» имеют побочные эффекты, отличные от распределения (поскольку в этом случае вы можете выразить небезопасные ситуации, когда два глобальных элемента взаимно зависят друг от друга). Кроме того, при динамическом связывании модулей может быть неясно, имеют ли разные библиотеки свои собственные экземпляры глобалов или глобальные глобальные ресурсы являются общими.
Тестирование и ограничение - источник, использующий глобальные переменные, несколько сложнее проверить, потому что нельзя легко установить «чистую» среду между запусками. В более общем смысле, источник, который использует глобальные сервисы любого рода, которые явно не предоставлены этому источнику, сложно проверить по той же причине.
Добавление глобалов действительно легко. Легко привыкнуть объявлять их. Это гораздо быстрее, чем думать о хорошем дизайне.
Глобальные переменные не так плохи, как вы думаете, их следует избегать всякий раз, когда они не нужны. Глобальные переменные могут найти хорошее применение для переменной, которая будет использоваться во всей программе, помня о том, что вы всегда должны отслеживать, где эта переменная принимает изменения; но для переменных, которые, как правило, используются только в ограниченных частях программы, есть веская причина избегать ее глобального использования.
Возможно, глобальные переменные не являются плохими в вашем случае. С другой стороны, они вам нужны? Что вы получаете, используя их?
Даже в вашем случае глобальные переменные затрудняют определение состояния приложения. Это может помешать отладке и может привести к незначительным ошибкам.
Глобальные переменные также усложняют тестирование. Они добавляют зависимости от внешнего кода, которых вы можете избежать во время тестирования.
Но, наконец, глобалов трудно избежать при программировании на C. На более продвинутом языке глобалы просто бессмысленны в большинстве случаев. Использование их просто не делает ваш код более понятным.
В Си есть много случаев, когда глобальные переменные являются просто лучшим, самым простым и чистым решением.
Так что в вашем случае принимайте это на индивидуальной основе. Вы, вероятно, в конечном итоге получите некоторые глобальные переменные, но не делайте переменную глобальной, если не уверены, что это действительно лучшее решение, не только сейчас, но и через год, когда вам придется отлаживать код или создавать приложение. многопоточный.
Код, который использует глобальные переменные, сложнее поддерживать. Поскольку сопровождающий должен найти каждое использование переменной в системе, прежде чем он сможет точно знать, что делает переменная. Поскольку это замедляет обслуживание, его следует избегать, насколько это возможно. Вот и все `
С помощью глобальных переменных часто трудно понять, где и когда они обновляются и какой фрагмент кода обновляет эту переменную. Нет контроля над тем, кто может его обновить или каким образом обновляется переменная.
Нетрудно отследить, является ли ваше приложение небольшим, но чем больше становится ваше приложение, и чем больше у вас глобальных переменных, тем больше код приложения выглядит как спагетти.
Короче говоря - это становится кошмаром обслуживания и отладки.
Хранение большинства переменных локально и уменьшение их объема помогает продвигать лучшие практики программирования. Это также снижает риск ошибочного изменения переменной и необходимости отслеживать через функции в поисках непредвиденных или неочевидных последствий. Я считаю, что это также облегчает чтение и обслуживание кода, поскольку большинство переменных, относящихся к определенному разделу кода, определены и инициализированы поблизости. В противном случае я, кажется, постоянно возвращаюсь к разделу кода, определяющему все golbals. Я использую некоторые глобальные переменные, но в основном для передачи информации о конфигурации в субмодули.
Одна из причин, которая приходит на ум, - это доказательство будущего. Возможно, вы сейчас являетесь единственным разработчиком вашего продукта, но, возможно, другие будут поддерживать его позже. Конечно, это может быть не так в вашем конкретном случае.
Хотя ваш продукт может быть небольшим и аккуратным прямо сейчас - где использование глобальных переменных не усложняет общий дизайн или не ухудшает читаемость - кто скажет, что продукт не станет намного больше или будет включен в другой продукт? И не дай бог другому сопровождающему / разработчику придётся разобраться с использованием глобальных переменных.
Конечно, вы можете решить использовать глобальные переменные сейчас, и когда проект становится все более сложным, вернитесь и переписайте его части, но зачем навязывать эту дополнительную работу себе? Вы с большей вероятностью (если вы вообще помните глобальные переменные) решите, что выполнять эту работу - это слишком много усилий, и позволить дизайну уйти: в этот момент у вас проблемы!
Итак , избавь себя от головной боли и задумайся о будущем. Необходимая работа сейчас, вероятно, облегчит жизнь в будущем.
Если это не убедило вас, представьте, что вы разработчики, которые работали над этим проектом и обнаружили, что их код был признан ошибочным и виновным в недопустимых практиках программирования перед Верховным судом: Код ошибки алкотестера отражает важность источника обзор
Проблема заключается в том, чтобы отследить, какой бит вашего последнего кода изменил состояние глобального. Как правило, вы хотите, чтобы переменные были в наименьшей возможной области видимости, чтобы вам было легче их рассуждать.
Это вопрос масштаба. У нас есть разработчики, которые любят создавать глобальные переменные для создания локальных концепций. Это усложняет отслеживание использования этих переменных, поэтому легче допускать ошибки при их использовании.
Вы также можете держать свой кошелек на переднем крыльце, но тогда у вас будет гораздо меньше контроля над тем, кто получает к нему доступ.
Тем не менее, есть некоторые допустимые варианты использования глобальной переменной, но, как и любое другое правило, заслуживающее внимания. Это исключение, а не нормальный случай. Их существующее указывает на то, что у них есть применение.
Если вы решили использовать глобальную переменную, постарайтесь комментировать их и давать им хорошие имена. Меня действительно беспокоит, когда люди создают глобальные переменные, такие как «bool bIsFound;»
Мы ставим точку в оценке каждой новой глобальной переменной в обзоре кода и проверяем, есть ли лучший подход.