[Pdx-pm] Readable code

Eric Wilhelm ewilhelm at sbcglobal.net
Mon Jan 10 23:18:21 PST 2005


# The following was supposedly scribed by
# James marks
# on Tuesday 11 January 2005 12:55 am:

>Now, however, as I read books on Perl and talk to Perl coders
>I'm finding that placing an emphasis on writing readable code, and
>breaking code out into lots of subroutines doesn't seem to be
>considered "the Perl way" of doing things.

Yes, but golfing isn't "the Perl way" for me.  I thought "the Perl 
way" was TMTOWTDI

>The emphasis seems to be 
>tighter and tighter code, sometimes - it seems to me - at the
> expense of readability (especially for those new to Perl).

I don't know.  I'm using Math::Vec here, so does adding array 
references inside of a map qualify as more readable or less?  It's a 
lot more transparent than a foreach loop or a subroutine call, and 
takes up as much space.

# totally out-of-context code
my @vecs = ($self->{edge_vec}, $prev->{edge_vec} * -1);
# get the framework lines (aimed away from corner)
my @fwsegs = map({[$pt, $pt + $_]} @vecs);

I do a lot of CAD/CAM and geometry code, so almost everything is an 
array.  IMO, this is exactly the perl way to do it, since we have 
garbage collection, etc.  The C/C++ way to do it seems to be to deal 
with things named x,y, and z, and then write all of the code 3 times.  
Sure, you can define classes, etc.  but perl lets you do that too.  
From my experience, SPOT is easier to achieve with perl, which helps 
readability because there is less to read and it is less scattered.

I guess the short answer is that good software practices are good.  I 
would say readability is one of them, and yes perl allows you to 
write unreadable code.  I don't think it encourages it.  English 
doesn't force readability on you either.

--Eric


More information about the Pdx-pm-list mailing list