I find this kind of logic to be ... less than satisfactory.
  1. Maintenance includes enhancements.
  2. Every single program will always need maintenance. Every single one.
  3. 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?

  1. You could pass it in to every function. That starts looking like tramp data.
  2. 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 .....)
  3. 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.

In reply to Why Globals can be a good thing by dragonchild
in thread where do you put your subs by greenFox

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.