Global Variables: Not a good practise?

Recently I was looking for a way to access a variable from everywhere in my Windows Forms application. I achieved this by using a public static class, but that is not the point.

When searching on the internet for this problem, I ran into comments that C# is designed to disencourage using global variables, and that the solutions are considered work-arounds.

Why is that What is wrong with using global variables

Visual C#11

C# is an OO language. Each object should hold its own state (includes the variables). OOP includes also encapsulation, which means that each object holds it's state internal and doesn't show it to everybody around the AppDomain (~ process). If you need a global setting or something, you should wrap it into a property and synchronize access via multiple threads by using the lock keyword. If you need a class that creates new instance of a certain type you could also have a look at the factory or singleton pattern.

indeed. you could still use global variables in classes which is fine but when it comes to exposing it to other classes, you are best to make an accessor property (get/Set or both) so the calling class can get or set the property in question, depending on how you are designing your application.

It is better to use the accessor property as you have more control over who should access what and if they are allowed to be able to set values or not.

It is ideal in the sense that you may wish to restrict the setting of properties/variables during say your runtime execution portion of your application. So users can get or set variables/properties when doing configuration but cannot set those values whilst executing say, a database procedure/query.

Let me tell you a story.

Once, a man named Patrick was asked to take over and modify a very complex C# GUI program from a previous developer. This developer had come from C and C++, where the use of global variables was prevalent, and the developer had little knowledge of the .NET namespaces.

When Patrick dug into the code, he found that the previous developer, having little experience in C#, had decided that he REALLY liked using global variables, and the only way to force C# to do things the way he wanted was to cram everything in the entire program into the same class, much to Patrick's chagrin. Where stuff couldn't fit into that class, he merely passed all of this forms and controls between each other, happily accessing objects in ways that would make your mother grimace.

The only way the previous developer could get things to work the way he wanted was to make everything visible everywhere. Unfortunately, he's programmed himself into a corner, and now the program is so rigid in its design that it's become useless (thus, why I was asked to rewrite it) and nearly impossible to maintain.

70,000 lines of code and almost 2 months later, Patrick has finally begun to get the code in working form so that he can actually make the modifications he was asked to make.

That's why you don't use global variables.

Hello All.

Patrick:

Well, now, hang on a minute. Just because there are drunk drivers, doesn't mean that we shouldn't use cars. I don't think that blanket prohibitions serve anyone's purpose, really.

Now, let me first say that I'm a firm believer that OOP is wonderful thing. But, I think that it is best-suited to library code (actually, perfectly suited). With application code, I think it suffers just a bit. For example, I don't think anyone can deny that having libraries of controls and components (Hooray, .NET!) is an excellent develpment, but how many times have we lamented the fact that a particular object doesn't quite do just what we wanted it to do

You see, I think that application code requires a greater degree of flexibility, because by nature it provides the interaction necessary between the various objects. Granted, flexibility can be taken to extremes, like the train wreck which you described. But that was a case of poor judgement, not bad tools.

I don't think that the judicious use of one or two global variables in a given scenario is automatically a cause for condemnation. I think it all comes down to using good judgement.

Well,

The only situation I had to use globals was to dynamically store a username and password for database access. I guess there are "normal" ways to do this, I just haven't figured them out yet *shame*

Mark Benningfield wrote:

I don't think that the judicious use of one or two global variables in a given scenario is automatically a cause for condemnation. I think it all comes down to using good judgement.

Actually I agree. I should note that my case is really an abberation; I will on occasion create a variable I make available everywhere, usually by just making it a public static member (this can be useful in the case of strings and configuration values). But before I do that, I really ask myself if it's necessary, because it's really easy to get carried away with it.

You should create a Settings class and implement the Singleton pattern (as I mentioned before in this thread). That will do it. It's no global variable then, but you specify only that you have ONE and only ONE Settings instance in your application. That Settings class has properties that return the username, password, connectionstring, whatever.

Have also a look at the settings found in the "Properties" folder of your project (if you use Visual Studio 2005).