Why are global variables bad, in a single threaded, non-os, embedded application

Question

Most of the objections I see to using global variables make sense since they refer to issues of multiple threads, thread safety, etc.

But in a small, single threaded

Answer 1

Code which uses global variables is harder to maintain. Since the maintainer must find every use of thevariable in the system before she can know precisely what the variable does. Since this slows maintainence it should be avoided as much as possible. That's it `

Answer 2

With global variables it's often hard to know where or when they are updated and what piece of code updates that variable. There is no control as to who can update it or in what way the variable is updated.

It's not that hard to keep track of if your application is small - but the larger your application becomes, and the more global variables you have, the more the application code looks like spaghetti.

In short - it becomes a maintenance and debugging nightmare.

Answer 3

It is a matter of scope. We have developers that love to make global variables to do local concepts. It make the usage of these variables much harder to keep track of, so it is easier to make mistakes in the use of them.

You can keep your wallet on your front porch also, but then you have far less control over who is accessing it.

That being said there are some valid uses for Global variable, but like any other rule worth following. This is the exception not the normal case. Their very existing points out that they have a use.

If you do decide to use a global variable try to comment them well and give them good names. It really bothers me when people make global variables like "bool bIsFound;"

We make it a point to evaluate each new global variable in code review and see if there is a better approach.

Answer 4

The short answer is that global variables have historically been the source of subtle bugs. But then (putting on my functional programmer hat) all variables have been sources of subtle bugs.

Basically, a global variable means that you can't look at a piece of code using the variable's value, and know what it's going to do without knowing what every other piece of code setting that variable's value has done in the past.

Answer 5

Perhaps global variables aren't bad in your case. On the other hand, do you need them? What do you gain by using them?

Even in your case, global variables make it harder to figure out the state of the application. That may hinder debugging, and it may lead to subtle bugs.

Global variables also make testing harder. They add dependencies on external code that you may wish to avoid during testing.

But finally, globals are hard to avoid when programming in C. In a more advanced language, globals are simply pointless most of the time. Using them just doesn't make your code any clearer.

In C, there are plenty of cases where globals are just the best, simplest and cleanest solution.

So in your case, take it on a case by case basis. You'll probably end up having some globals, but don't make a variable global unless you're sure it's actually the best solution, not just now, but also a year from now when you have to debug the code or make the application multithreaded.

Answer 6

One reason that comes to mind is future proofing. You might be the only developer on your product now, but it's conceivable others will maintain it later. Of course this might not be true in your particular case.

While your product might be small and tidy right now -- where using global variables doesn't complicate the overall design or compromise readability -- whose to say the product will not become much larger or be incorporated into another product? And god forbid another maintainer/developer come along have to sort out your use of global variables.

Of course, you could decide to use global variables now and when the project appears to be getting more complex go back and rewrite portions of it, but why force that extra work on yourself? You're more likely (if you remember the global vars at all) to decide doing that work is too much effort, and let the design go: at this point you are in trouble!

So, save yourself the headache and design with your eye on the future. The work required now will probably make life easier in the future.

If that didn't convince you, imagine being the developers who worked on this project, and had their code found faulty and guilty of bad programming practices in front of the Supreme Court: Buggy breathalyzer code reflects importance of source review