On Tue, Jan 25, 2022 at 09:53:25AM +0000, rempas via Digitalmars-d wrote:
> It is known that people dislike global variables and the reason is that they make the code harder to debug.

The problem with global variables is that firstly, it modifies the behaviour of a function apart from its parameters. This in itself may not seem like a big deal, but a global variable also means it can be modified by anyone and everyone at any time.  So you may have a call to function F from module A, but you can't tell what the result will be, because it depends on whether module B modified the global variable before you called F.  Changing the order you call a pair of functions may drastically change their behaviour in unexpected ways if they both modify the same global variables.

In a small project this is not a big deal, but in a large project it makes it almost impossible to debug, because how F will behave changes depending on the entire code path leading up to the call to F (whether anybody along that path changed the global variable and what they changed it to).  When you're faced with a bug report, you generally don't have enough information to tell exactly which path the code took before it got to F, which also means you can't tell how F will behave. When this happens not just for one function F, but for every other function in the code where the bug is, it makes debugging an extremely unpleasant experience.

Another problem with global variables is that there can only be *one* instance of that global. Suppose you have a database-driven program where basically every function needs to access the database connection. Well, why not make it a global variable? Easy peasy.  Well, then one day, you decide that you need to add a second database connection (maybe for syncing, backup, or merging, whatever). Now what? ALL of your functions assume that only a single connection exists. To add a second connection you now have to rewrite every single function in your program (and/or hack it by swapping the single global variable between two connections -- very error prone and almost inevitably leads to tons of bugs and impossible situations).  Had you written your functions to take the database connection as a parameter, inconvenient as it may be, it would have been a trivial code change: just pass the 2nd connection and you're done.


> In my experience tho, it is the exact opposite. When I have a variable that I must pass down to 5-6 functions, I find it much easier to make it global rather than having it been passed in all the functions that need it.  This practice also makes my function signatures looking much cleaner.  Yeah, one variable will not make a difference but in my project, I have about 2-3 variables that need to be passed down to a lot of functions so I only think that it makes sense to use them as globals.

Whenever you have multiple shared parameters between a bunch of functions, that's a sign that they probably should be member functions of a common struct or class.  The shared parameters should be in the struct, then you don't have to explicitly pass them around, you just add another function to the struct and they gets passed implicitly for you.


> Another problem is the case that I'll introduce a new variable that needs to also be passed in most of my functions. What happens then? Let's say I will have 20 functions at the time. I have to change both the function signature and all the other places in code that call this function. The latter can be easily done with a quick "search and replace" in my text editor but still, it's a tedious thing to do.

Either group your parameters in a single struct, or make your functions members of the struct. Then all you have to do is add another field to your struct and you're done. No tedium.

Using a struct/class also takes care of the instancing problem: if one day you suddenly need a different set of parameters, you just create a different instance of your struct and everything Just Works(tm). If they were global variables, then there can only be one instance of every variable, and you're stuck up the creek without a paddle.


T

-- 
Don't drink and derive. Alcohol and algebra don't mix.

On 1/25/22 01:53, rempas wrote:

> people dislike global variables

The situation is much better in D because I suspect what you call global is D's module-scope and thread-local.

(Note: I don't want to argue whether thread-local by default was a good decision or not but I certainly take full advantage of the ease of thread-local variables in D.)

So, module-scope variables are just fine: std.parallelism uses a default ThreadPool object, std.stdio functions use stdout, in this case a truly global object, etc.

> When I have a variable that I must pass down to 5-6
> functions, I find it much easier to make it global rather than having it
> been passed in all the functions that need it.

I've used that method once, which I mentioned at this point during a presentation:

  https://youtu.be/dRORNQIB2wA?t=2946

Both you and I realize that a module is an object and in our case there is a single object of it. That works.

When you need more than one object (more than one context), then you move all those variables to a user-defined type and they become proper member variables.

> global variables can mess me up

Otherwise, as everybody else told, global variables can be very dangerous:


https://www.safetyresearch.net/toyota-unintended-acceleration-and-the-big-bowl-of-spaghetti-code/

That report mentions "thousands of global variables", all of which I bet started as "what can go wrong?"

Ali

On Tuesday, 25 January 2022 at 15:47:12 UTC, Ali Çehreli wrote:
> ... https://www.safetyresearch.net/toyota-unintended-acceleration-and-the-big-bowl-of-spaghetti-code/...


This is a good read, other than this paragraph:

"Other egregious deviations from standard practice were the number of global variables in the system. (A variable is a location in memory that has a number in it. A global variable is any piece of software anywhere in the system can get to that number and read it or write it.) The academic standard is zero. Toyota had more than 10,000 global variables."

I couldn't help feeling like the article was describing a particular .NET project my job has me assigned to.

On Tue, Jan 25, 2022 at 07:47:12AM -0800, Ali Çehreli via Digitalmars-d wrote: [...]
> Otherwise, as everybody else told, global variables can be very dangerous:
> 
> https://www.safetyresearch.net/toyota-unintended-acceleration-and-the-big-bowl-of-spaghetti-code/
> 
> That report mentions "thousands of global variables", all of which I bet started as "what can go wrong?"
[...]

Further down the article it states "Toyota had more than 10,000 global variables."  That's... wow.  They must have inherited that code from the 80's or somewhere thereabouts, when this was the accepted way of coding. By today's standards, I should be surprised there aren't *more* accidents than there were(!).

And also, the other points in the article about failsafes and single points of failure, all jive with what Walter has been telling us about airplane design. :-D


T

-- 
If you think you are too small to make a difference, try sleeping in a closed room with a mosquito. -- Jan van Steenbergen