[Chicago-talk] Perl Style

Jim Thomason thomasoniii at gmail.com
Wed Aug 18 21:22:07 CDT 2004


> 1) variable names
> 2) function names

I'm tragically non-standard. I'm trying to break myself of the habit
and be consistent one way or the other. Variable names I tend to
follow perl style with underbars between words. $this_is_a_variable.
functions/methods I'll change, sometimes (sigh...usually) in
mid-module. I haven't quite put my finder on why, yet.

$object->insert_columns looks fine, but $object->inserColumns doesn't.
$object->isBindable looks fine, but $object->is_bindable doesn't.

I'm trying to correct things as I see them in my code to the
underscore style. Of course, it's slightly complicated for me because
studly caps are the preferred style in objective-C.

> 3) the "{" after a function

Goes on the same line as the function.

sub foo {

}

So do opening if statements.

if ($something) {

}

I'll switch around the placement of elsif/else blocks.

if ($something) {

} else {

}

if ($something) {

}
else {

}

Sometimes one or the other looks better. I'm not particularly married
to either of them. I dislike opening braces on the start of a line.

>anything else in particular

I used to love but now hate the perlish way of putting single line ifs
on the same line as the braces.

if ($something) {somethingShort()};
else {otherShortThing()};

It looks too jumbled to me nowadays. 
(note - see? I'm back to studly caps already)

I've also grown to really like inline pod. Inline tests are nice, too,
but I'm starting to clutter up my code a bit more than I'd necessarily
like. I think it's the lesser of the evils vs. having them external.

Basically, the only maxim that I really am concerned with is spacing
out your code. Whitespace does an incredible amount for clarity of
software. Put related bits of processing on subsequent lines, but put
spaces between unrelated (or loosely related) bits. Put a few more
spaces between less related items. It helps to visually break up the
software into chunks which makes it easier to read, I find.

Oh, and I follow the old Einstein quote of making things as simple as
possible, but no simpler. Naturally, perl people love compact code.
And I do think it's advantageous - shrinking stuff down more leaves
less room for bugs. Just don't shrink to the point that clarity
suffers.

-Jim....


More information about the Chicago-talk mailing list