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 ]

Ovid (2709)

Ovid
  (email not shown publicly)
http://publius-ovidius.livejournal.com/
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Thursday February 01, 2007
06:18 AM

'killkillkill' x 255 if $some_condition

[ #32294 ]

I was looking at crud like the following:

$dbh->prepare('SELECT foo, bar ...
$dbh->prepare('SELECT quux, bar ...
$dbh->prepare('SELECT this, that ...
$dbh->prepare('SELECT and, more ...
$dbh->prepare('SELECT of, this, crap ...

Multiple prepare statements in a row? What gives?

If you think it's acceptable to write a line of code that's much more than 80 characters long and you think it's OK to have a statement modifier at the end where they are hanging off the right side of my terminal window, you desperately need to have all of your fingers run through a sausage grinder and sit at home and reflect on your sins.

$dbh->prepare('SELECT foo, bar ...') if $1 == $bar;
$dbh->prepare('SELECT quux, bar ...') if $in_dev;
$dbh->prepare('SELECT this, that ...') unless $i'm_on_drugs;
$dbh->prepare('SELECT and, more ...') if !$undulating;
$dbh->prepare('SELECT of, this, crap ...') if $bar == 3;

There are so many things wrong with that, I can't even begin to understand how the programmer ever got hired. Fortunately, this is, once again, legacy code that we've complete permission to fix.

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.
  • With folk who live on terminals maximised horizontally, so they end up with 400char wide lines.

    No excuse of course...
    • These are the same people who don't understand what's wrong with 500 line subroutines which do 23 unrelated things.

      • Indeed. I have to be much more careful with advice like "if it doesn't fit on half a screen it's too complex" for folk have a display with more characters than I had pixels when I were a lad :-)
      • The code in the top level post is bad but even if the guy had a normal sized terminal going it still would have been bad code, just easier to see it all.

        My PuTTY session is set up to start at 157 x 60 which after screen is up and running gives me 157 x 58 and fills the entire display. Are you saying that more display real estate equates to bad code?

        People with more display real estate shouldn't be lumped in with the clueless masses who churn out chum. I don't write the 500 line subroutines that do 23 d

        • As a general rule of thumb, I've seen that the longer individual lines of code are, the worse the code quality. However, that's only a rule of thumb and certainly not a hard and fast rule. What's important here is whether a programmer can look at a particular bit of code and understand what's going on. The "larger" the code (wider or taller), the lower the chance of that happening.

          If a programmer is writing code that other programmers will have to work on -- now or in the future -- it's even more imper

          • As a general rule of thumb, I've seen that the longer individual lines of code are, the worse the code quality. However, that's only a rule of thumb and certainly not a hard and fast rule. What's important here is whether a programmer can look at a particular bit of code and understand what's going on. The "larger" the code (wider or taller), the lower the chance of that happening.

            I agree with you; I just wanted to get you to elaborate a bit. :)

            If a programmer is writing code that other programmers will have to work on -- now or in the future -- it's even more imperative to follow reasonable guidelines which most people will accept. A 76 to 80 character width for lines is one of those guidelines :)

            I agree again. This is why we use perltidy with a shared configuration file. No matter who runs perltidy the results will end up looking the same (unless they explicitly override the options on the command line).

          • I hit submit too soon.

            I was fairly certain that you would say something similar to what you actually did. I wanted you to say it though (if that makes any sense to you).

          • I refuse to break my code at unnatural spots just to fit an obsolete limitation. 1024×768 is ubiquitous and permits much wider lines than 80 chars.

            That doesn’t mean I make my lines gratuitously long. I usually stay a good deal below 80 chars, because my code style is generous with whitespace and has plenty of natural breaking points – very deliberately so. Eg. were I to write the exact same code as your example, then each line would be broken before the if, which would follow on an inde

  • Perhaps someone was paying by the line.
    • They learned that habit at the Charles Dickens School of Computer Science.

  • unless $i'm_on_drugs;

    ...is that you're using a package 'i'. :P