Naming Convention For Global Variables?

Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

Replies are listed 'Best First'.
Re: Naming Convention For Global Variables? by kcott (Archbishop) 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	[reply] [d/l] [select]
Re: Naming Convention For Global Variables? by locked_user 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. CountZero 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	[reply] [d/l]
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	[reply]
Re^2: Naming Convention For Global Variables? by LanX (Saint) on Sep 28, 2012 at 11:12 UTC
perldoc -u perlvar \|perl -ne '$seen{$1}=1 if /(\$[A-Z_]+)\b/}{ print +join "\n", keys %seen' $ERRNO $RS $OSNAME $OUTPUT_FIELD_SEPARATOR $EXTENDED_OS_ERROR $LAST_SUBMATCH_RESULT $COMPILING $PREMATCH $OFMT $OUTPUT_RECORD_SEPARATOR $FORMAT_NAME $SUBSCRIPT_SEPARATOR $LIST_SEPARATOR $WARNING $EUID $FORMAT_LINE_BREAK_CHARACTERS $OS_ERROR $FORMAT_FORMFEED $PERL_VERSION $I $INPUT_RECORD_SEPARATOR $DEBUGGING $NR $REAL_USER_ID $CHILD_ERROR $PID $FORMAT_TOP_NAME $EVAL_ERROR $FORMAT_LINES_LEFT $POSTMATCH $EXECUTABLE_NAME $ACCUMULATOR $EXCEPTIONS_BEING_CAUGHT $FORMAT_LINES_PER_PAGE $LAST_PAREN_MATCH $OLD_PERL_VERSION $ORS $OUTPUT_AUTOFLUSH $EGID $ARRAY_BASE $BASETIME $REAL_GROUP_ID $EFFECTIVE_GROUP_ID $SUBSEP $OFS $ARGV $PROGRAM_NAME $SIG $FORMAT_PAGE_NUMBER $UID $SYSTEM_FD_MAX $INPUT_LINE_NUMBER $GID $INPLACE_EDIT $MATCH $LAST_REGEXP_CODE_RESULT $PROCESS_ID $EFFECTIVE_USER_ID $PERLDB $_ [download] Cheers Rolf UPDATE: added underscore	[reply] [d/l]
Re^3: Naming Convention For Global Variables? by tobyink (Canon) on Sep 28, 2012 at 12:56 UTC
With the exception of `$ARGV` none of those variables are used by perl itself. They are specific to English.pm (see English) and are documented in perlvar for convenience (even though barely anybody uses English.pm). `perl -E'sub Monkey::do{say$_,for@_,do{($monkey=[caller(0)]->[3])=~s{::}{ }and$monkey}}"Monkey say"->Monkey::do'`	[reply] [d/l]
Re^4: Naming Convention For Global Variables? by LanX (Saint) on Sep 28, 2012 at 15:02 UTC
Re^3: Naming Convention For Global Variables? by Anonymous Monk on Sep 28, 2012 at 11:24 UTC
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.` [download]	[reply] [d/l]