Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

This question was brought up during a Standards discussion, which should revolve around SOLID Principles for Object Oriented Development.

In your experiences, have you seen benefits or drawbacks in either code readability or performance based on whether variables are passed ByRef vs Module-Level Variable?

Obviously: If a method calls a submethod, which will not only use but also modify a parameter, it should be passed as a reference pointer (aka: ByRef).

Based on this logic, some in my discussion are very strict to never use module-level variables.

In response, I say we have a toolbox and should know when to use what tool. For example, a sub declares a variable. That sub calls a function, which calls a sub, which calls a function, which calls a sub, etc etc, and eventually that variable is changed 10 methods down the line.

I'd say make that variable a module level, whereas some say pass it ByRef through your tree of methods.

So where is the line when examining SOLID OOP Principles?

Do you go with an extreme?:
Never use ByRef, or Never use Module-level Variables.

Or do you set a routine depth?:
1-method, always ByRef; 2 deep, consider it; 3-depth, Module-level Variable.

Or maybe a Branching Principle?:
If, in your list of methods, the variable is really only updated in one place then passed ByRef all the way back up to the original... ByRef them all. But if the variable is changed during multiple stages in multiple branches of the tree of methods, make it a module level.

If the latter is the case, should that also mean 20 methods down the line, ByRef all the way back up to the original is still fine? Or maybe a hybrid of these possible rules. What's your take on it?

share|improve this question

1 Answer 1

up vote 1 down vote accepted

First off, in programming rules there are no absolutes. Every rule that is stated as an absolute has its share of exceptions.

With that out of the way, you should avoid using module-level variables as much as you should avoid global variables. Apart from the portion of the program that can access them, the two share the same problems. Just about any advise against using global variable applies equally well to module-level variables.

share|improve this answer
    
Module-level variables can produce the exact same problems as global variables: race conditions; difficulty in "de-globalizing" a global or module-level variable; increased debugging effort, since not all modifications are visible in the stack. The best type of variables are by value and not by reference; if that is not feasible, by reference is second-best. –  Frank Hileman Jul 22 '13 at 23:11
    
@Frank, I agree. I've found Subs with a single ByRef and had to refactor for them. Sometimes the issue is a lack of following the Single Responsibility rule. So when you refactor, the ByRefs just simply go away. Proper ByRefs are < 2% of param types and are just one tool in a devs toolbox. So my question may seem easy to answer to say try not to use ByRefs or Module vars, but I'm not wanting an overall absolute rule, I'm asking about that rare occassion: Pass down 10+ levels of methods, or use a module level. When your company outputs hundreds of programs a year, you run into it enough. –  Suamere Jul 23 '13 at 14:26
    
@Suamere: Although ByRefs are rare, Module vars (and globals) should be rarer still by, IMHO, at least an order of magnitude. If you have to pass a parameter through that many levels of methods, you might have to reconsider other aspects of your design. –  Bart van Ingen Schenau Jul 23 '13 at 14:58
    
Gotcha. Any pro's or con's from anybody about the opposing view? I'm not a fan of either ByRef's or Module vars, but at least for readability I favor a rare module var over a byref. Any performance opinions? –  Suamere Jul 23 '13 at 18:32
    
Global variables and publicly modifiable module variables (fields) do have advantages. If you are creating a system where you are truly modeling something that will always be process wide (or appdomain wide), such as a dictionary based on the types loaded, it makes sense. Or, if you are writing an API that will always be accessed via non-instance methods. Or some quick hack code that will be thrown away. –  Frank Hileman Jul 24 '13 at 0:33

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.