Are global variables bad?

Question

I have developed certain financial and accounting packages on the basis of global variable which is I want to share. Here I present the small example of global variable which is communicated between multiple forms.

Form1 :-  
Component require :-
1.  ComboBox
2.  Button


using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Text;
using System.Windows.Forms;
using System.Data.SqlClient;


namespace Globalvaribale
{
public partial class Form1 : Form
{
    public static string name;

    public Form1()
    {
        InitializeComponent();
    }

    private void button1_Click(object sender, EventArgs e)
    {
        name = comboBox1.Text;
        Form2 f2 = new Form2();
        f2.Show();
    }
    private void Form1_Load(object sender, EventArgs e)
    {

        string connstr = "server=.;initial catalog=maa;uid=mah;pwd=mah";
        SqlConnection con = new SqlConnection(connstr);
        con.Open();
        string sql = "select name from dummy";
        SqlDataAdapter dap = new SqlDataAdapter(sql, con);
        DataSet ds = new DataSet();
        dap.Fill(ds);
        comboBox1.DataSource = ds.Tables[0];
        comboBox1.DisplayMember = "name";
        comboBox1.ValueMember = "name";

    }
  }
}

Form2

Component is Label1

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Text;
using System.Windows.Forms;

namespace Globalvaribale
{
public partial class Form2 : Form
{
    public Form2()
    {
        InitializeComponent();
    }

    private void Form2_Load(object sender, EventArgs e)
    {
        label1.Text = Form1.name;

    }
  }
}

And thus I have prepared all my project which is works very well and no compliant on it. Note that there is more than 50 winforms on each projects. But recently I have noticed: Global Variables Are Bad.

Some people call me “mad” to utilize this type of global variable. The above article suggests many disadvantages, and I am confused that if it is true, than how are my projects and applications successful without any errors or mistakes?

Answer 1

Global variables itself are not bad. Using them without thinking is bad.

You might consider using singletons, but if it's not really big & complex application, it might be safer to leave it as global var.

Answer 2

It is certainly possible to write code that works with global variables. Even code that works well. It is just that in most cases (which does not include all cases, but very, very likely, your one), not using global variables, once you get used to that, makes reading and maintaining the code much, much easier, and writing it not much harder. Most of the time. There are times for global variables, certainly, but trying to reduce their number as far as reasonably possible helps in the future – not only, but most obviously, when you are trying to make your code multithreaded.

The problem with this global variable issue is that the drawbacks of global variables are hard to show in short examples, so they have to be experienced in real-world code. They strike especially hard with code you “inherited” from some other programmer no longer reachable – but after a while, your own past projects will probably be numerous enough that the difference between your own old code and old code written by someone else will be much less than you previously thought or experienced.

---

Edit: Since you asked, I'll try to describe what I mean by an example.

Assume you use some logging mechanism, with a global variable pointing to where the output should go.

std::ostream *out = &std::cout;

void log(Object &o const) {
    *out << "Log: " << o.getSomeData() << std::endl; // or whatever
}

If you want log messages somewhere else, you'd simply assign out to some other value, call log and set it back. Easy enough, right?

std::fstream logfile("operation.log");
std::ostream *oldLog = out;
out = &logfile;

someOperation();

out = oldLog;

Now, the first problem with this is that the code above fails to reset out in case of errors. The C++ way around that would be to use some RAII object, other languages need explicit try/catch blocks or whatever. Nothing complicated, it just makes the code a little more verbose.

But what happens if some code inside someOperation() wants to write log messages itself, which are not meant to go into some specific log file? It needs to temporarily set out back to &std::cout again. Doable, of course, but it needs to be done in all those places – and the interface of log does not necessarily make this clear.

You may not have a problem keeping all these cases in mind. For me (and a lot of others), keeping all this global state in mental memory is something that takes up space where other things cannot go any more. Sure, to change the code, I need to have additional parameters, which has costs of its own:

someOperation(std::fstream("operation.log"));

or

std::fstream logfile("operation.log");
logfile << someOperation();

or some other option. But I gain that I can look at code locally and see much more easily (i.e., without going through my knowledge of 800 global variables in 372 files of 5k lines of code each) what happens.

Now, factor in other developers who may have other ideas of “clean code” than you do – and for me, the size and complexity of projects I can do on my own is limited. Most code these days is written in teams, I believe.

Answer 3

Global variables are not bad per se.

In fact, sometimes it is a blazingly simple solution to a really complicated problem. Instead of passing the same value between dozens of classes in different layers, one could just use a single global variable. I've done this and it has greatly simplified the code.

The reasons why it is considered bad have to do with potential dangers. Note the word potential.

1. Global variables represent a global pool of data where everybody is eligible to read/write. As the code grows, you risk losing control over who writes what, when and how.

2. You make many classes and modules dependent on one little thing. One little change and you have to rework lots of your code. A small bug and it will have repercussions everywhere.

This is very old knowledge and experience gathered in the days of functional programming before OOP came in. Like with many other questionable practicies, you have to know the risks. Whether you will get into trouble, depends on you. To coin a phrase, it's not about global variables, it's how you use them.

In your specific case I do not believe a global variable is a good solution to what you're doing. If you explained the idea behind your code, we might give you better alternatives.

Answer 4

Global variables really can come in handy. But they come at a cost.

Relying on global variables tends to create tightly coupled designs. It is hard to run parts of your program in other contexts, because it expects this global context to be in a certain state.

This kind of coupling can get in the way of (unit) testing. As you want to run stuff out of context or in a controlled context.

Global variables also tend to lead to designs with side effects. A function / method will produce a side effect by altering global state that is not obvious from the code surrounding the code to this function. This can lead to bugs that are hard to track down.

Answer 5

Having just started working on a legacy project with tens of global variables, I have to say that I'm opposed to using them.

They're not bad per se, but they can infinitely complicate maintaining the code:

• They introduce a lot of unexpected behaviors, simply because it's extremely hard to track their values.
• They can be modified by anyone, anywhere, at any time.
• Removing them is much harder once your code base has grown.
• Decoupling different modules becomes a real issue, if most of them are intertwined by these global variables.

If you're the only one working on the project, and you know what you're doing, you can use them, nothing's going to explode. Just don't expect to understand why your project's working in a particular way years down the road.

Answer 6

Well, let's consider why globals are considered bad. It's their unconstrained visibility. Global variables are accessible to all code, for reads and modifications. A design based on proliferation of globals, defeats structure. The reads and writes can come from anywhere. And while this may be OK when you first implement something (because you know the land), it can be catastrophic because of the kind of code it encourages. Soon you end up with a spaghetti of relationships and interactions.

Having said this, a blind hatred of globals is also not warranted. I mean, globalness can be relative. A class name is global within a namespace. A class member is global within the namespace established by the class. So, if the codebase for a class becomes large enough, the same argument made against globals, can likely be made against class members. In fact, namespaces and classes are, in part, mechanisms to contain this disease of globalness. They are (in part) mechanisms to draw boundaries of visibility and access.

So, in my view, the question is not of globalness. It's really about structure.

Answer 7

When i have too many global variable i will create new static class (or more than one class) and I'll put this variables in that class so later its more easy to find this variables and their behavior.

public static class CommonGlobal
{
    public static string XName {get;set;}
    public static int x {get;set;}
    ....
}

This class will be initialized just one time, and if i change the Form1 class (in your sample) there is no need to change all of classes which uses Form1.name because i have CommonGlobal.XName, so the UI changes make a little change in my code and keeps my business Free from extra changes, without adding any layer i have a layering accessibility. so sometimes developer calls it Common layer, but in fact its not a layer its just a Common and shared items. and there is no difficulty to use it or change it. For better practice see the structural patterns like this.

Answer 8

There are already excellent answers, but I'll give you my experience.

The most obvious reason not to use globals the way you did above, is that the day you will have to open two or more Form1, nothing will work anymore. And one day you will need it.

In a large project I'm working on, we made the design mistake of storing some application-wide objects in a static class -they were unique in the application-. This backfired in a spectacular way when a part of our application needed to be used in a different context as part of a multi-threaded engine (yes I know ThreadStatic, but there were other reasons as well). All of a sudden those objects were not "unique" anymore (as every thread needed their own) and we had to redesign a lot of things.

In general I'm not a fan of over-design and don't like to make things super complicated just to support possible but very unlikely future scenarios. However this is a case were the effort to do things in a more proper way is usually not huge (if you do it from the beginning) and the probability you'll gain benefits is high.