DISCLAIMER: THESE PAGES ARE STILL UNDER CONSTRUCTION. NO CODE EXAMPLE BEEN TESTED YET.

Perl - my idiosyncracies

Variable and subroutine naming conventions


[Previous Page] Table of Contents: small | med | large

Variable naming conventions [back to top]

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:


© 2001 Steve Hwan, hostname: @pacbell.net, username: svhwan
You should probably use the word "PERL" in the subject line to get my attention.
Last Modified: Tue Apr 24 09:33:59 2001