Kenneth Ismert
kismert at gmail.com
Wed Dec 22 11:20:14 CST 2010
My take: There is no need for global object references. Public subroutines and functions in plain old modules provide all the global visibility that is required. Lambert is right -- global variables got their bad name because can be changed or destroyed by any code at any time. Globals make using code among projects harder. For sharing, you want your modules as self-contained as possible. And philosophically, I think globals promote a passive, 'reference-based' style of programming ... "Change this global, and the app should behave differently", "Do this [with an implied global in some indeterminate state]". State is lazily maintained. This often leads to "programming that is so complex, nothing is obviously wrong". What I am striving for is an active style: "Do this with this". Code is functional -- it acts only on what is given, and returns only a result. This style has no side-effects: no inputs are modified, and global state is not changed. Classes rely on external function libraries -- even module-level variables are too public! Classes written this way become 'light-weight', carrying only the 'what', not the 'how', and become much easier to understand. When most of your code is in function libraries, writing tests becomes feasible. You can't achieve purely functional code in VBA (for that, you'd need Haskell). But still, the goal is to write "code that is so simple, nothing can possibly be wrong". -Ken