Not golfing, because you won't get decent code from
golfing horrible code.
I'd rather see this code as a spot-the-mistakes execise.
Thus, here come my changes:
my @quarters = qw/none first second third fourth/;
sub termgrades {
my ($period, $quarter) = @_;
$sth = $dbh->prepare_cached(
qq{SELECT *
FROM $quarters[$quarter]quarter
WHERE userid = ? AND period = ? AND gradetype = ?}
)
or &error( "2", "$userdata[0] $quarters[$quarter] quarter "
. "grades database search failed: $DBI::errstr" );
$sth->execute( $userdata[0], $period, 2 )
or &error( "2", "$userdata[0] quarter grades "
." database search failed: $DBI::errstr" );
}
update
Changed the @quarters array
to avoid a minor bug. Thanks to itub.
However, the first blunder, the one that eventually led
to the current horrible code, is that there are four
database tables instead of one.
Thus the first order of business would be to
merge those four tables into one, adding a "quarter" column.
With that in mind, you could rewrite the above function
as follows:
sub termgrades {
my ($period, $quarter) = @_;
$sth = $dbh->prepare_cached(
qq{SELECT *
FROM quarters
WHERE userid = ? AND period = ?
AND gradetype = ? and quarter = ?}
)
or &error( "2", "$userdata[0] quarter $quarter grades "
. "database search failed: $DBI::errstr" );
$sth->execute( $userdata[0], $period, 2, $quarter )
or &error( "2", "$userdata[0] quarter grades "
." database search failed: $DBI::errstr" );
return $sth; # perhaps ... see text
}
That said, this function, in its original form, is completely
useless, because it is executing a SELECT request from a locally
scoped statement handler, and its result would be simply lost.
A returning statement for such a handler is needed, if you want
to pursue any practical purpose.
What else? Ah, yes, the global @userdata array,
of which we have just to assume it exists and has valid data
in it. It should be passed as an argument as well.
FInally, that naked numeric literal "2" used as an argument
to "execute" and "error" should be turned into a variable, so
that whoever has to maintain the code knows what it is about.
-
Are you posting in the right place? Check out Where do I post X? to know for sure.
-
Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
<code> <a> <b> <big>
<blockquote> <br /> <dd>
<dl> <dt> <em> <font>
<h1> <h2> <h3> <h4>
<h5> <h6> <hr /> <i>
<li> <nbsp> <ol> <p>
<small> <strike> <strong>
<sub> <sup> <table>
<td> <th> <tr> <tt>
<u> <ul>
-
Snippets of code should be wrapped in
<code> tags not
<pre> tags. In fact, <pre>
tags should generally be avoided. If they must
be used, extreme care should be
taken to ensure that their contents do not
have long lines (<70 chars), in order to prevent
horizontal scrolling (and possible janitor
intervention).
-
Want more info? How to link
or How to display code and escape characters
are good places to start.