I think it's pretty standard to name numerical iterator variables
$i, $j, and $k, especially if you're
just iterating of indicies of a point or a color.
For other iterator variables, I often like to end them with
'Ndx'. For instance, $patchNdx.
I like to end a lot of my hashes (but not all of them) with the name 'Hash'.
I like to end a lot of my arrays (but not all of them) with the name 'List' (because it's shorter than 'Array') or by using plurals. I usually try to keep my scalars with the singular form.
Finally, I try to begin most of my references/pointers with an 'r_'. This also applies to objects. When a hash ref is encapsulated by an object definition, good OOP would say to just think of it as that object and to ignore the underlying structure. I started doing this briefly. But after just one program, I changed my mind, and found that I really like seeing that 'r_', and am considering going back through that one program and adding all the 'r_'s back.
For example, if I was dealing with a bunch of Nurbs patches, you might see a block of my code that looks like:
sub processPatches {
my $r_patchList = shift;
my $r_matList = shift;
my(@patches) = @{$r_patchList};
my(@materials) = @{$r_matList};
foreach my $patch (@patches) {
my $materialNdx = $patch->{'materialBinding'};
my $material = $materials[$materialNdx];
# do something to the patch...
# and do something with a material
my(@color) = @{$material->{'Cs'}};
for (my $i=0; $i<3; $i++) {
&setComponent($i, $color[$i]);
}
}
}
I borrow a convention from the world of C++. (It's not an inherent part of C++, but a lot of programmers seem to follow this convention.) If I have a function or a variable that I would prefer that other people do not use, I'll begin it with an underscore (_). I think there used to be a special meaning to that as far as scope, but there isn't anymore.
I'll mention that there are ways that you can actually prevent someone from accessing a variable, and even a subroutine if you're creative. However, I discourage this practice so much that I'm not even going to say where you can find out how to do it.
Now, if I wanted to discourage the use of
processPatches, I would say:
sub _processPatches {
my $r_patchList = shift;
my $r_matList = shift;
my(@patches) = @{$r_patchList};
my(@materials) = @{$r_matList};
foreach my $patch (@patches) {
my $materialNdx = $patch->{'materialBinding'};
my $material = $materials[$materialNdx];
# do something to the patch...
# and do something with a material
my(@color) = @{$material->{'Cs'}};
for (my $i=0; $i<3; $i++) {
&setComponent($i, $color[$i]);
}
}
}
To be clear, anyone will still have access to this subroutine. It is not truly private. But I feel strongly that true private variables should never be used. The underscore should be a sufficient signal to other programmers that I discourage the use of this function. However, if they get in a bind and they really do want to use it, they can. I figure that if it was useful to me, it could be useful to someone else too.
I will reiterate: