Databases are for storing global variables. We usually call them “rows” or “records” instead, but they’re definitionally global variables: any part of your…
Yes always is probably wrong, but not having global state allows you to argue just by function signature and allows easier unit testing and multithreading and probably more.
The thing is - you almost always have “a global state” of sorts it’s just all about how you access it. And the guidance is to do so though well defined interfaces as you say.
But sometimes a global variable really is a good solution. A logger or config object can often be handled pretty well as “global” vars. You don’t generally want to pass loggers to every single function call.
They’re not. This is what we tell beginners because one needs to be careful when maintaining a global state and beginners often do it horribly.
But having a global state is sometimes the right solution.
Pro tip: if you ever find yourself saying “x programming practice is always wrong” you’re probably wrong.
Yes always is probably wrong, but not having global state allows you to argue just by function signature and allows easier unit testing and multithreading and probably more.
The thing is - you almost always have “a global state” of sorts it’s just all about how you access it. And the guidance is to do so though well defined interfaces as you say.
But sometimes a global variable really is a good solution. A logger or config object can often be handled pretty well as “global” vars. You don’t generally want to pass loggers to every single function call.