I find this kind of logic to be ... less than satisfactory.
- Maintenance includes enhancements.
- Every single program will always need maintenance. Every single one.
- A maintainer will want to be able to read the code easily, to be able to determine where best to make the change.
Global variables are a feature. If you misuse this feature, then you will be bitten. This is the same if you misuse any feature. There are perfectly good reasons to make some variables global. However, just like injudicious use of map and grep and $_ (some or all of which some code shops ban, to improve maintainability), misusing globals can reduce maintainability. Using them intelligently can IMPROVE maintainability.
For example, let's say that you have an object that you use to do your logging. It's a one-stop-logging machine that you use in every single function you have. What options do you have to make sure it's in scope in every function?
- You could pass it in to every function. That starts looking like tramp data.
- You could make it a Singleton and have it grabbed every time. This simply makes the classname a hard-coded value in your code. (Or, the classname is now a global .....)
- You could make the logger (or logger class) global. (Of course, heavy commenting would help here, as well as a set of standards.)
Remember, the only difference between a constant and a global is that the global can change. But, if you use 2-5 globals in your entire application and they're well-named and well-documented up-front, you shouldn't have any problems.
Remember - you can always try to get the idiot out of the programmer by force, but it's better just to educate and document. You'll have more success that way.
------ We are the carpenters and bricklayers of the Information Age. Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement. | [reply] [Watch: Dir/Any] |
| [reply] [Watch: Dir/Any] |