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.
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)