Почему глобал это плохо и за него бьют по рукам?

В языке они есть и мой вопрос можно решить только таким методом как я думаю

здесь да

а почему бы не передать как параметр в функцию?

параметр чего?У меня есть глобальные переменные и исходя из их параметров которые меняются в ходе программы эта же программа реагирует

Если бы я знал как иначе сделать я бы сделал

У меня есть ответ

Недостатки глобальных переменных:

1. Неконтролируемый доступ. Так как они не передаются явным образом, к ним можно легко получить доступ с помощью из слоев абстракции, которые о них не должны вообще знать.
  Пример такой ошибки: обращение в БД из html-шаблонов

2. Усложнение использования кода из-за неявных связей. Невозможно глядя на функцию понять, что ей нужно для работы.
  Например, если мы вызываем функцию foo, а она вызывает функцию bar, а так вызывает функцию baz, которая обращается к глобальной переменной XXX, мы не можем догадаться что XXX надо иницилизировать для использования foo.
  Это можно документировать, но наличие такой документации невозможно проверять автоматически.

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

4. Сильное сцепление. Так как переменная инициализируется там же откуда её импортируют, в результате косвенно весь код использующий переменную сцеплен с кодом её иницилизации.
  В результате код использующий такую переменную невозможно использовать не втаскивая конкретный код инициализации.  

5. Невозможность иметь два экземпляра без изменения кода, использующего их.
  Пример, раньше использовалось одно соединение с БД, но при повышении нагрузки часть запросов решили делать в read-only реплику.
  В случае DI изменения так же потребуются, но есть возможность выбрать, где будет приниматься решение об использовании конкретного соединения, и не менять контракт использующих его частей.    

6. Все выше сказанное усложняет тестирование кода.

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

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

Параметр функции

пугает только первое и то не понятно как это работает

типа уязвимость

Это все не про уязвимость, а про возможность потом твой код как-то поддерживать

Чтобы тот, кто будет его править, не охуевал и не перерисывал половину

у меня есть 5 функций к примеру которые надо запустить и они запускаются только при условии если моя переменная имеет то или иное значение и эта глобальная переменная меняется другими функциями.И как я могу без использования глобальных переменных это решить при условии если count = 1 это 5 работающих def и 15 отключенных.

и запускать их надо при определенных условиях

и чтобы программа это видела и реагировала подругому

Слышал про ООП?

да

классы сложно для меня ещё

Создай классы, передай им одинаковые или разные настройки и управляй