Replacing the global variables, how and why

Question

Ok so I have worked and used my global variables until now, and it has been no problem in just calling $USER to get the user id.

Most times from people on SO and some reading here and there, it all has been so negative towards using the global var.

So now i am ready to change the way and not using global variables.

Right now i include a function, protect() which checks your session and makes the global variables such as $USER, $USERTYPE .

And then i can just use these variables as much as i want in the file.

What can replace this? I have thought of making $USER = grabUserid(); that will return the user id, and same for the user type, thats already 2 functions and i would need to make function with database queries for every variable then?

And what about my $connect, which is a PDO object for the database, handling all my queries, i would need to do $connect = connectdb(); too

And what about http requests with js to another php file, i would need to pass it, but then between there it can be unsafe (if you think of security) as you can just manipulate the user id between there..

Or maybe theres a third solution of doing this? Or should i just stick to the globals? And once and for all please mention why globals vars are so bad? is it security? or the look of dirty coding?

Answer 1

So this question is really two questions: why would I stop using global vars, and how should I implement similar functionality with another construct.

First, why you might want to stop using global vars:
Let me say that not using global variables is not a rule so much as a guideline. While there are zealots on both sides of the issue, there are some good reasons for and against it (though I've heard more against than for). Some reasons you might want to avoid global variables:

1. Access control
   This is probably the biggest and most solid reason for not using globals. With the global variable construct, any code can use the data stored in the variable any way it wants regardless of scope or reason. Access rules can be broken and the data can be invalidated by a reckless write. Unverified access means untrustworthy data.

2. Concurrency
   If you have a global variable, which by definition have no explicit access rules, concurrency can be a real issue. If two concurrently running instances or functions are accessing that same data, there is no way to guarantee the order in which reads or writes happen - further polluting your data.

3. Coupling/Structure/Code Clarity
   Simply put, when you're using global vars in OOPHP, it's likely you're coding your way around passing your data in a more direct way. Writing with globals implies tight coupling between the procedures using that data, as well as makes it difficult to understand the data flow. Refactoring is almost a necessity in most cases.

Second, how you can avoid global vars:

1. Static Vars/Objects
   One of the best ways to avoid globals is to wrap your "global" data in a static object. This allows you the minimum level of code safety of creating getters and setters around the data that can either bound check, access restrict, or at the least data lock your global variables as necessary. It may be a bit extra coding, but the level of data security you gain is worth it.

2. Refactor
   Think about the reason you're using your global data. Are you just trying to get around passing that data between functions? Are you trying to create persistent data that could be just as easily (and more effectively) be handled by $Session ? Often globals are stopgaps for quick and easy configurations or session work. Using config files or sessions add a level of functionality, extensibility, and security that is often worth the extra work.

There are a few cases where globals can be useful. In very small programs, where data security is entirely irrelevant, or where your data is TRULY used throughout the code with no good clear way of passing it or avoiding scope issues, it may be alright to use global vars, but in general they're bad practice.

A good way to think about it is "what would happen to my script if my global data turned out to be garbage." If the answer is anything but "not much, really," then you should probably find a way to protect that data or to rethink the way you're using it.