Slash Boxes
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 ]

schwern (1528)

  (email not shown publicly)
AOL IM: MichaelSchwern (Add Buddy, Send Message)

Schwern can destroy CPAN at his whim.

Journal of schwern (1528)

Saturday January 05, 2008
02:59 AM

Good style and quick scripts.

[ #35292 ]

This is an excerpt from an email exchange I'm having about the pros and cons of applying good style to short scripts.


There is a common fallacy that good style is slower to write. Seems sensible, generally it's generally more verbose and more to type. And so for short scripts and experiments it's acceptable to use short, sloppy styles. It might be true that optimizing for number of keystrokes saves you in the immediate term, but an efficient and good style recoups that loss over the course of writing even a single page program term by reducing debugging time.

When applying a good, efficient style one does not have to be careful or think very hard about what you're writing. If you make a mistake it will generally blow up in your face with a good error message. Case in point, strict. If you typo a variable the code won't compile and it will tell you exactly where the mistake you made is. Without strict the code runs and you don't know what went wrong until, maybe, you get a use of uninitialized value warning. But that comes at the point where the variable was used, not where the mistake was made.

But then you probably didn't turn on warnings either--it's a short script, what could go wrong--so you get nothing but silence. Maybe you get mysteriously empty output. Maybe you get an error about calling a method on undef. Who knows? And who knows what went wrong?

Now you have to spend time debugging what went wrong. Worse, you're lacking an error message pointing to the problem. If you're lucky you have an error message pointing somewhere further down the line, then you have to work your way backwards. At worst you have no error message.

All the time you saved not typing "my" a few times is lost many times fold with an added bonus of hair pulling "WHY ISN'T THIS WORKING?!" frustration. And this is all in the short term construction period before the script will even run, not weeks or days or even hours down the road.

Using $_ is another example. You must consider and avoid anything which might alter or overwrite $_, and if you don't you get no warning or error.
As soon as something goes wrong you risk spending frustrating
minutes debugging, far more than was gained through avoiding typing out the LHS of a regular expression.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • Once I developed a style, I just use it everywhere; it's easier than thinking about doing some other way. That'swhat Jon Rockway just said. [] :)

    As for short scripts, I usually add warnings and strict once I encounter the first problem. I should probably have some sort of script that opens a ready-to-go template for me (and I even already have that template), but I don't.