Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask

Naming Convention For Global Variables?

by Anonymous Monk
on Sep 28, 2012 at 10:52 UTC ( #996168=perlquestion: print w/replies, xml ) Need Help??
Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:


is there any convention to capitalize or uppercase global variables?

PBP doesn't give me a hint there.

In my case those variables are set in an initialisation sub and quasi constant for the rest of the modules, thats why I $UPPERCASED them.

But that's in conflict with perl special vars ...

Any suggestion? Maybe $Capitalize ?

Thanks Kurt

  • Comment on Naming Convention For Global Variables?

Replies are listed 'Best First'.
Re: Naming Convention For Global Variables?
by kcott (Chancellor) on Sep 28, 2012 at 11:29 UTC

    G'day Kurt,

    I'd disagree that PBP doesn't give a hint. Chapter 3: Naming Conventions - Capitalization (page 45 in my copy) certainly gives a hint.

    If by quasi constant, you mean a variable whose value isn't intended to be changed; why not make it an actual constant? If, for some reason, you can't do this, you can still treat it as a constant as far as naming is concerned: e.g. $CONSTANT_VAR_NAME. If you meant something else by quasi constant, please explain.

    I'm not really sure what you mean by "... in conflict with perl special vars ...". The obvious answer is to pick a different name; however, I suspect you're not referring to variable names in perlvar. Please clarify.

    Personally, I try to avoid global variables wherever possible. In cases where this isn't possible, I'd typically use something like: $Global_Var_Name.

    -- Ken

Re: Naming Convention For Global Variables?
by sundialsvc4 (Abbot) on Sep 28, 2012 at 12:31 UTC

    What I do is to use constant to define constants, and, insofar as possible, I define one application-wide place in which I store global values of interest.   That place is an object, and there is a subroutine which is used to return its value.   This subroutine, and all others like it, creates and initializes the necessary “singleton” structure on-demand the first time it is called.

    Since the global-values stash is an object, with methods, this gives me a fine degree of control and a good debugging-point.   When other parts of the system need access to a particular value, I want them to go through a short subroutine at a single known location to get it ... ditto for manipulating the value.   The actual variable that stores the value is in a private scope.

    You see, any and every use of a “global anything” creates an undocumented coupling among all of its various clients, “wherever they might be,” and nothing traceable “happens” when they refer to it.   I don’t like that, largely because I deal with so much crufty code that did that.   Replacing a global value with a short sub that returns it is one of my many “tricks.”

    It works for me because in my case I can easily afford the “extra” microseconds that it takes.   There are others here, e.g. BrowserUK, who will have an entirely different perspective because they ordinarily deal with very CPU-intensive problems that have to squeeze the CPU-clock for every nanosecond that it can spare.

Re: Naming Convention For Global Variables?
by CountZero (Bishop) on Sep 28, 2012 at 20:42 UTC
    Whatever works for you is OK. And if you document it and abide by your own rules, then it should be OK for any future maintenance programmer looking after your code.

    Personally I limit the use of all uppercase (lexical) variable-names to filehandles.

    I try not to have really global variables. Any data should go in and out of modules, objects, subroutines, functions, ... only through parameters and return values and never through global variables. The scope of my variables is limited as much as possible.

    I only have one exception and that are global configuration parameters, which are always inside the %config hash and are only accessed through this hash.


    A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

    My blog: Imperial Deltronics
Re: Naming Convention For Global Variables?
by Anonymous Monk on Sep 28, 2012 at 11:03 UTC

    But that's in conflict with perl special vars ...

    No it is not


      Cheers Rolf

      UPDATE: added underscore

        With the exception of $ARGV none of those variables are used by perl itself. They are specific to (see English) and are documented in perlvar for convenience (even though barely anybody uses

        perl -E'sub Monkey::do{say$_,for@_,do{($monkey=[caller(0)]->[3])=~s{::}{ }and$monkey}}"Monkey say"->Monkey::do'

        Where is the conflict?

        $ perl -wE " say $BASETIME " Name "main::BASETIME" used only once: possible typo at -e line 1. Use of uninitialized value $BASETIME in say at -e line 1.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://996168]
Approved by LanX
Front-paged by kcott
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (11)
As of 2018-10-16 12:28 GMT
Find Nodes?
    Voting Booth?
    When I need money for a bigger acquisition, I usually ...

    Results (85 votes). Check out past polls.