Subject: The Fine Art of Naming Things - Re: array numerical name... - msg#00291

On Tuesday, April 30, 2002, at 09:18 , Jackson, Harry wrote:

Is the following more suitable or is it bollocks as well.

keeping timothy's kind and gentle rebuke in mind.....
{ my complements timothy!!! }

There are two sets of competing concerns:

a) get the code to work
b) have code that can be maintained

{ and when the money is right, they may even pay you to
write 'safe' code.... but never hold your breath on it
until the law suit backs them up against the wall on needing
to have 'security' right up there with 'quality' ... }

That the code runs under strict and with warning means that
it clearly passed a more stringent set of issues on (a) than
code that is 'in production' - the problem is with 'b' - and
hence my core concern with

my $TRY = "world";
my %TRY;

note that at a quick glance

$TRY{$h}=3;

it is possible to 'obsese' on the '$TRY' part...

So as a general rule of thumb try to lay out the variables
that you plan to use in a way that is less likely to leave
any shadow of a doubt as to what is really going on.

As chas' recent kvetchings noted - there comes that time,
at 'oh dark squat' when you are typing and not thinking....

Many of us 'old guys' were so excited when compilers were
able to use both upper and lower case letters, as that meant
that we could extend the range of our variables and function
names to things like

$DamnYankee = getCarpetBagger(@arglist); #honest it is one word...

rather than all in upper case. with the inclusion of "_" in
the token list of parsables that could be used we can "expand"
that line to what is argued to be a more readable

$Damn_Yankee = get_Carpet_Bagger(@arglist);

Your Mileage may vary - but this clearly easier to get an idea
about than say

$a = cb(@b);

So since one has a wealth of lexical tokens to create - why not
do the decent thing and avoid putting scalars and list variables
so close together in the name space.

Granted at times I tend to do sillies on gp:

my %tmpHash = ();

so that when I stumble across it later on as

$tmpHash{$key} = $val ;

I have the awareness that I am putting that val at that key
in that hash..... not that I am trying to do some triple
expansion value eval that will allow me the hyperAreobesque
into a much happier place... { that at times there are need
for things like @{<stuffhere>} should be left for when you
really need to be doing that... }

yes, I know that I have production code with embedded jokes:

@list_shrugged....

but at least at a glance I know that I have a list...

So the first trick is to protect the 'name space' - NOT
for the compiler - Pork The Compiler - but so that you are
not going to get lost in your own code - I am still in the
debate between the 'import' v. 'direct call' approach:

use Wetware::DTK;
...
my @cool_list_of_Things = &Wetware::DTK::getCool(@list_shrugged);

as opposed to

use Wetware::DTK qw/:cool :weird/;
...

my @cool_list_of_Things = getCool(@list_shrugged);

But that way leads us into where i expect a percentage
of folks will wind up - they did enough perl that they
wind up with enough basic 'site local' functions that
having a perl module is a rational extension....

So the naming the variables and functions games should start
simple and stay simple as long as you can ... to recycle the
old cobol joke:

"If you mother can read your code and understand it....
then there is half a chance management will too...."

And more importantly that YOU will at that odd hour.

Once one is in the habit of thinking about naming variables
appropriately - then one starts also natively thinking in
terms of what sort of 'data structures' come 'native' to
the coding language that one is in.

In /bin/sh - there is really no such thing as a list - and
worse yet one has no such critter as a hash so you wind up
doing things like

LONGHASH="key:val key1:val1 key2:val2"

so that one can do the

for entry in $LONGHASH
do
# suck out the key val pairs here
eval `echo $entry | awk '{
split($0,spot,":");
print "KEY="spot[1] , "VAL="spot[2] }'`

echo "Have $KEY and $VAL"

done
{ and people sed that things were so awkward in shell... }

So if one finds that the data starts laying out that way, and
one always did the above in /bin/sh - why do it in perl?

$LONGHASH = "key:val key1:val1 key2:val2";

why not simply DO the

%long_hash = (
key => 'val',
.....
);

and go with the ugly duckling

while ( my ($key, $val) = each %long_hash ) {
print "Have $key and $val\n";
# and did with them as I will....
}

All of which then leads to the:

Why try to globellate:

print @array$a[$b];

when one should look at the data - and decide if one
is trying to be a coder - or is one trying to find a
way to get something else to do the data analysis and
matching of the data to the data structure for you?

Simply so that one can funk around have have funky
expansions that look almost like

World0[$a] ....

IF the compiler actually generated up 'strings' to
manipulate - rather than FUNKY 'bit streams'....

The Text IS Your Side of the Line. The 'bit stream foo'
you should leave to the compiler.

At which point when you get to:

print ${"array$a"}[$b] ."\n"

you will notice that it required an inline 'interpolation'
of the double quoted string to find a reference to an array.

and you are of course out and away into the land of complete
WakkaDoodelEdge....

please READ Jeff's Comments:


Mark-Jason Dominus has an article about why using a variable as a name for
a variable is a bad idea. Symbolic references are a left-over artifact
from The Land Before Perl 5. They are wizardry, and should be avoided
99.9% of the time. There's about ONE place where you should use them, and
even then, you probably don't need to.

http://perl.plover.com/varvarname.html


please DO read mjd's article.

IF you still feel an exception emotional need to work in
that space - feel free to find a planet that matches the
colour of the sky in your world..... and do send postcards....

8-)


ciao
drieux

---