Re: Coding superstitions

[seattlejohn]

Personally, I'd use the term "conventions" rather than "superstitions". (I guess they are superstitions the way there are superstitions about breaking mirrors, which is to say, if I ignore them, I'll fear I'll have seven years of maintenance headaches, er, I mean bad luck.)

Aside from the usual syntactic stuff (how many spaces to indent each level, anyone?), some of mine are:

• Use parens liberally in expressions, to minimize unexpected precedence weirdness. And more importantly, because I find it easier to read code I (or somebody else) has written if I don't have to think through the precedence implications in a complex expression; I can do it, I just don't think it's a good use of my (or anyone else's) time.
• Use descriptive variable names. With a few exceptions my variable names are almost always real word(s) separated by underscores. This way I don't have to worry about whether I called some variable $usraddr or $useraddr; I know it's going to be $user_address. (I also like to think it would be easier to grok for someone who's a non-native English speaker, though that's just speculation.)
• On a similar note, avoid using $i, $j etc. for loop variables. Instead, I use a convention like this:
  foreach my $this_address (@address_list) { ... }
• Avoid $_ in most circumstances. I'd rather be explicit about what values I'm using, simply because I find it easier to read later.
• Semicolons after nearly every line (even if they're the only line in an else). Comma after the final element of a hash/array assignment (unless I'm using qw{}).
• use strict, use warnings, test return values of system calls, etc. etc. etc. Any opportunity to let the computer find my errors instead of having to hunt them down myself!
• try to use constant instead of hardcoding any constants in my logic. (I fear I'm far from perfect on this front, though.)
• write POD as I write the code. Write tests before (or at least concurrently with) the code.
• always check CPAN/Perlmonks etc. before going off and writing a "utility" sub -- because somebody has probably already done the work, and quite possibly done it better than I would have.