Why people dislike global variables so much while I find them so convenient?

H. S. Teoh hsteoh at quickfur.ath.cx
Tue Jan 25 16:41:17 UTC 2022


On Tue, Jan 25, 2022 at 04:19:31PM +0000, Kyle via Digitalmars-d wrote:
> 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.

Don't worry, it happens more frequently than most people would like to
admit in "enterprise" software.  After having dealt with "enterprise"
code for several decades, I do not have many good things to say about
it. I often like to allude to one particular project I had the
misfortune of being assigned to, where on one occasion I had to go
through 6 layers of abstraction just to make a single function call --
one layer of which involved fwrite() of the arguments into a *temporary
file* (yes, in /tmp/) and fread()'ing it from the other end of an RPC
call.  (Happily, the component that that particular piece of code was in
has since been trashed and rewritten from ground up -- without those
egregious useless layers of abstraction.)

And unfortunately, "deviations from standard practice" are IMO not an
accurate description of the industry; IME spaghetti code with tons of
global variables and other code smells *are* the de facto standard
practice in "enterprise" code, esp. those of significant size and worked
on by large teams of programmers.


T

-- 
Don't modify spaghetti code unless you can eat the consequences.


More information about the Digitalmars-d mailing list