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.
Re:I've seen this happen...
Ovid on 2007-02-01T11:39:06
These are the same people who don't understand what's wrong with 500 line subroutines which do 23 unrelated things.
Re:I've seen this happen...
Adrian on 2007-02-01T11:46:01
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:-) Re:I've seen this happen...
Mr. Muskrat on 2007-02-01T15:32:04
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 different things. I find myself writing long lines of code all too often but that's what perltidy is for.
:) Re:I've seen this happen...
Ovid on 2007-02-01T16:00:55
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 imperative to follow reasonable guidelines which most people will accept. A 76 to 80 character width for lines is one of those guidelines
:) Re:I've seen this happen...
Mr. Muskrat on 2007-02-01T16:47:34
I agree with you; I just wanted to get you to elaborate a bit.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 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).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
:) Re:I've seen this happen...
Mr. Muskrat on 2007-02-01T16:57:19
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).
Re:I've seen this happen...
Aristotle on 2007-02-02T00:11:49
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 indented line of its own. The result is that I run up to 95 columns or so with any frequency, maybe every once in a couple dozen lines; up to 115ish maybe once or twice per file, if even that often; the most I’ve had more than two or three times is in the 130s or so. I do try to find a way to keep line lengths down, I just refuse to bend over backwards to uphold the rule.And in any case if I ended up with a long sequence of conditional bits of code, all with different conditions, like what you have there, I’d ask myself whether there really is no better way to write that. Code consisting entirly of short conditional bits is every bit as painful to read as code full of GOTOs.
Re:How were they getting paid?
Ovid on 2007-02-01T16:55:31
They learned that habit at the Charles Dickens School of Computer Science.
unless $i'm_on_drugs;