Jump to page: 1 27  
Page
Thread overview
Why people dislike global variables so much while I find them so convenient?
Jan 25, 2022
rempas
Jan 25, 2022
bauss
Jan 25, 2022
rempas
Jan 25, 2022
rempas
Jan 26, 2022
rempas
Jan 26, 2022
bauss
Jan 26, 2022
bauss
Jan 25, 2022
max haughton
Jan 25, 2022
rempas
Jan 25, 2022
max haughton
Jan 26, 2022
rempas
Jan 26, 2022
max haughton
Jan 27, 2022
rempas
Jan 25, 2022
forkit
Jan 25, 2022
rempas
Jan 25, 2022
Dennis
Jan 26, 2022
rempas
Jan 25, 2022
jmh530
Jan 25, 2022
jmh530
Jan 26, 2022
rempas
Jan 26, 2022
jmh530
Jan 27, 2022
rempas
Jan 25, 2022
H. S. Teoh
Jan 26, 2022
rempas
Jan 26, 2022
H. S. Teoh
Jan 27, 2022
rempas
Jan 26, 2022
rempas
Jan 27, 2022
rempas
Jan 25, 2022
bachmeier
Jan 26, 2022
rempas
Jan 26, 2022
bachmeier
Jan 27, 2022
rempas
Jan 25, 2022
Ali Çehreli
Jan 25, 2022
Kyle
Jan 25, 2022
H. S. Teoh
Jan 25, 2022
H. S. Teoh
Jan 25, 2022
Patrick Schluter
Jan 25, 2022
H. S. Teoh
Jan 26, 2022
rempas
Jan 25, 2022
Dukc
Jan 26, 2022
rempas
Jan 25, 2022
forkit
Jan 26, 2022
rempas
Jan 26, 2022
forkit
Jan 26, 2022
forkit
Jan 26, 2022
Basile B.
Jan 27, 2022
rempas
Jan 26, 2022
Mark
Jan 27, 2022
rempas
Jan 26, 2022
Bienlein
Jan 27, 2022
rempas
Jan 26, 2022
MrJay
Jan 26, 2022
H. S. Teoh
Jan 27, 2022
forkit
Jan 27, 2022
H. S. Teoh
Jan 27, 2022
max haughton
Jan 27, 2022
rempas
Jan 27, 2022
rempas
Jan 27, 2022
rempas
January 25, 2022

It is known that people dislike global variables and the reason is that they make the code harder to debug. 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. 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.

So can someone make examples about how global variables can mess me up. I know that probably everyone here has more personal experience than me so I really want to learn why global variables are considered so harmful.

January 25, 2022

On Tuesday, 25 January 2022 at 09:53:25 UTC, rempas wrote:

>

It is known that people dislike global variables and the reason is that they make the code harder to debug. 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. 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.

So can someone make examples about how global variables can mess me up. I know that probably everyone here has more personal experience than me so I really want to learn why global variables are considered so harmful.

The problem with globals is that anyone and anything can modify it.

It becomes especially problematic when your program receives input from elsewhere such as connections like sockets, http etc. or even other threads.

In my opinion globals are fine IFF they're only initialized once (and only one place is allowed to modify them) and/or they're immutable

Globals are extremely convenient to use and that's also why they're extremely dangerous to use.

January 25, 2022

On Tuesday, 25 January 2022 at 09:53:25 UTC, rempas wrote:

>

So can someone make examples about how global variables can mess me up. I know that probably everyone here has more personal experience than me so I really want to learn why global variables are considered so harmful.

Harder to debug. Harder to reason about as your program grows in size. Harder to scale your program to higher degree of concurrency. But there is a place and room for everything.

If you use globals you should keep them local to one object-file and limit access to accessor functions to make it easier to debug your code.

If you only use globals because you want to have fewer parameters then the common approach is to instead use a context-object and pass that as single parameter.

Unfortunately, D made the mistake of making thread-local the default, and claimed this was a great improvement. Thread local globals are basically something you only want to use in runtime and framework "kernel" like code. That gets you an additional layer of issues, including performance.

If you use globals, make sure you either mark them appropriately so that you don't get thread local globals.

January 25, 2022

On Tuesday, 25 January 2022 at 09:53:25 UTC, rempas wrote:

>

[...]

Passing state down a huge chain is also a code-smell. Writing code that uses a "global" variable is only slightly better than using a global variable.

What is the rough outline of these functions?

January 25, 2022
On Tuesday, 25 January 2022 at 09:53:25 UTC, rempas wrote:
>
> So can someone make examples about how global variables can mess me up. I know that probably everyone here has more personal experience than me so I really want to learn why global variables are considered so harmful.

If a computational path requires the use of a global variable, then use it.

What will mess you up, is not the global variable, but whether you know - for certain - the computational path(s) that use that global, and what effect those paths may have on that global.

It's pretty straight forward ;-)

January 25, 2022

On Tuesday, 25 January 2022 at 10:22:17 UTC, Ola Fosheim Grøstad wrote:

>

Harder to debug

How?

>

Harder to reason about as your program grows

What does this mean? No, I'm not joking, I truly don't get it. Do you mean "reason" as the reason they exist and what they do?

>

Harder to scale your program to higher degree of concurrency

Why? What's the difference between having a variable in a global space vs passing a pointer and having to difference it when it comes to concurrency? In both cases, you need to check if what you are trying to use is already in use (unless you don't care, lol!).

>

If you use globals you should keep them local to one object-file and limit access to accessor functions to make it easier to debug your code.

I mean, if you keep them local to an object file that they lose their bigger advantage. How many functions will be in this file compared to the whole project? So we don't win much.

>

If you only use globals because you want to have fewer parameters then the common approach is to instead use a context-object and pass that as single parameter.

Yeah but in that case, I will have to create an object and use pointers. And also use a pointer for this object and have to dereference it every time. So yeah, the runtime performance will not be happy about that...

>

Unfortunately, D made the mistake of making thread-local the default, and claimed this was a great improvement. Thread local globals are basically something you only want to use in runtime and framework "kernel" like code. That gets you an additional layer of issues, including performance.

If you use globals, make sure you either mark them appropriately so that you don't get thread local globals.

How can I do that?

January 25, 2022

On Tuesday, 25 January 2022 at 10:18:50 UTC, bauss wrote:

>

The problem with globals is that anyone and anything can modify it.

It becomes especially problematic when your program receives input from elsewhere such as connections like sockets, http etc. or even other threads.

In my opinion globals are fine IFF they're only initialized once (and only one place is allowed to modify them) and/or they're immutable

Globals are extremely convenient to use and that's also why they're extremely dangerous to use.

This will be a big problem with libraries but I don't see it been a big problem with non-library type applications. At least if I understand correctly what you are saying (which I probably don't).

January 25, 2022

On Tuesday, 25 January 2022 at 10:22:59 UTC, max haughton wrote:

>

Passing state down a huge chain is also a code-smell. Writing code that uses a "global" variable is only slightly better than using a global variable.

What is the rough outline of these functions?

What "rough outline" of a function means? Sorry if that sounds but I need to learn.

January 25, 2022
On Tuesday, 25 January 2022 at 10:54:59 UTC, forkit wrote:
> If a computational path requires the use of a global variable, then use it.
>
> What will mess you up, is not the global variable, but whether you know - for certain - the computational path(s) that use that global, and what effect those paths may have on that global.
>
> It's pretty straight forward ;-)

Thanks! Actually, that's exactly how I see it. I only want to use them when necessary. Also it seems that they can be dangerous only when used in libraries and when other people can modify them (when they shouldn't) but I was mostly talking about applications...
January 25, 2022

On Tuesday, 25 January 2022 at 11:37:54 UTC, rempas wrote:

>

On Tuesday, 25 January 2022 at 10:22:17 UTC, Ola Fosheim Grøstad wrote:

>

Harder to debug

How?

>

Harder to reason about as your program grows

Because the program is larger, there are more locations that could mutate the global state. ("reason" ≈ "prove correct")

> >

Harder to scale your program to higher degree of concurrency

Why? What's the difference between having a variable in a

  1. globals are singletons, it becomes difficult to have multiple instance if you later regret having only one instance.

  2. because you need to use locking correctly to prevent multiple threads from mutating the state at once and then you have to prove that your locking strategy is does not lead to starvation or deadlocks.

>

I mean, if you keep them local to an object file that they lose their bigger advantage. How many functions will be in this file compared to the whole project? So we don't win much.

I don't understand what you are trying to say here.

The global variable should be local to the object file. The accessor functions can be globally accessible.

>

Yeah but in that case, I will have to create an object and use pointers. And also use a pointer for this object and have to dereference it every time. So yeah, the runtime performance will not be happy about that...

Passing one pointer isn't particularly expensive. What (non-TLS) globals save you on some CPUs are registers and time spent on allocation.

For instance, using globals can make sense in embedded programming on tiny CPUs with very little RAM.

> >

If you use globals, make sure you either mark them appropriately so that you don't get thread local globals.

How can I do that?

https://dlang.org/spec/attribute.html#gshared

« First   ‹ Prev
1 2 3 4 5 6 7