'with' bug?

[Chris Cain]

On Sunday, 4 November 2012 at 14:59:24 UTC, Faux Amis wrote:
> I failed to mention that I am mostly talking about private 
> module scope variables. I don't see how private module scoped 
> vars make for less testable, readable or more bug prone code.

It's not like I feel that you should never use them, but what he 
says is right. The more open access that is given to a variable, 
the more difficult it is for the programmer to know what will 
access or change it. That becomes a huge problem in many 
languages that don't use thread-local variables by default, but 
it's still a problem in D.

Without using some sort of automated search, you can't know where 
in the module a variable is accessed or changed. Sometimes even a 
search will be insufficient:
---
module a;
int b; // the variable we're interested in
int c;

void blah() {
    foo();
    bar();
}

void foo() {
    c = b + 1;
}

void bar() {
    b *= 3;
}
---

So, via search, we can see that b is being accessed in foo, and 
being changed in bar. However, a simple search will not tell us 
that blah is accessing and changing b. Furthermore, any function 
that uses blah will also be accessing and changing b. The reason 
this is a problem is that it's "hidden" from the people reading 
the code. You might not know that using "blah" will write and 
read from b, which might effect the behavior of the call to "bax" 
later on in your code.

Consider this code, however:

---
void main() {
     int b = 5; // the variable we're interested in
     int c = blah(b);
     // What's the value of b here? How about c?
     bax(b);
     flax();
     bongo();
     for(d; sheep(c))
        blast(d);
     // Do you still know what b is? Of course you do!
}

int blah(ref int b) {
     int c = foo(b);
     bar(b);
     return c;
}

void foo(int b) {
     return b + 1;
}

void bar(ref int b) {
    b *= 3;
}

void bax(int b) {
    // large switch statement on b for behaviors
}
---

Now we're explicit in what uses b. All of a sudden, we can reason 
much more about the code without doing nearly as much searching. 
We know who depends on the value of b and who might change b. If 
we allowed it to be a global variable, or a module variable, or 
even a static struct variable, we might not always have such a 
good grasp on what is happening to it.

And if you don't have a good grasp on what's happening to the 
state of your program, you might introduce bugs. Hence, it's bug 
prone to use module scoped variables.

As for testability: if the behavior of your code depends on 
globals (and/or module-scoped variables), then it should be 
obvious why it's more difficult to test. Tests shouldn't be 
effected by tests run before nor should they have an effect on 
tests run after. When you use globals, your code will violate 
that by definition. Unless, of course, you spend time being very 
careful to reset globals before and/or after each test. That 
certainly makes testing more difficult and error prone, though.


Now, that all said, it's not like a velociraptor will jump 
through your window and eat your face off if you use a global or 
a module scoped variable. I'm sure you can come up with examples 
of where it might be beneficial or preferable. But it's something 
that should be avoided where you can.

Here's a good resource on why global variables are bad: 
http://c2.com/cgi/wiki?GlobalVariablesAreBad

Most of those reasons are applicable to module-scoped variables 
as well. Even struct static variables can still be problematic 
for some of the same reasons.