Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

ferreira (5993)

ferreira
  (email not shown publicly)
http://www.ferreira.triang.net/

Just another Brazilian Perl hacker.

Journal of ferreira (5993)

Thursday September 06, 2007
01:46 PM

Programming in Perl is hard

[ #34365 ]
I failed miserably when trying to write a simple sub &strip to trim leading and trailing spaces, modifying its argument in-place. My attempt was:

# in-place version
sub strip { s/^\s+//; s/\s+$//; }
# which would be used as
strip($msg);

promptly corrected by Aristotle in, not one, but two flavors:

sub strip { $_[0] =~ s/^\s+//; $_[0] =~ s/\s+$//; }

# or maybe

sub strip { s/^\s+//, s/\s+$// for $_[0] }

When I first thought about it, I believed my sin was failing to find the topic. I mistakenly assumed the sub parameter was already the topic, while one of the variants by Aristotle did not use $_ and the other used a proper mechanism the modifier "for $_[0]" to set it right. To tell the truth, my version works if used just as strip(), acting on whatever is in $_. (More on this on a later blog entry.)

My mistake was like saying

stripping the string is eating the leading and trailing spaces from something

where that something was left hanging like a dangling pointer. The phrase below would be more correct:

stripping the string is eating the leading and trailing spaces from it (the string)

My programming error (in Perl language) was like an ordinary error in a phrase in casual conversation (in natural language). And the major culprit was not proof-reading what I wrote.

(Of course, it is also an issue of proficiency. More practice would often imply a smaller defect ratio that could have set me free of that shame. But this proficiency only sets higher the threshold where mistakes are more likely. They will happen anyway the issue is whether they have discovered out there or while in the domestic environment.)

So while writing prose calls for proof-reading, programming calls for documentation and testing to be complete. With documentation, we make clear what is the purpose of the code (even though $_ = "this "; strip() works, it was not what &strip was supposed to do). The tests would establish a certain level of confidence on the operation of the code, at least as long as the usage was captured by the test cases. Extrapolation is always an enterprise with unknown consequences.

I was guilty of being a light commenter, typing faster than my brain takes to write a correct piece of code of 34 touches. But it will never be easy. Fortunately, after Aristotle, some careful documented design and testing, many pieces of code will be as robust as most applications need.

Ok. The entry title was provocative. It only means: Programming is hard. And you already knew that.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • use [cpan.org] CPAN.pm [cpan.org];

  • Although you're modifying it in place, at some point you'll probably accidentally do $msg = strip($msg); - and $msg will get the return value of the last substitution - which is the number of substitutions performed.

    I'd much prefer the subroutine instead returned $_[0] (although I rarely write modify-in-place routines, so maybe it just doesn't match my style, YMMV)