Seuf sends us some old code, which entered production in 2011. While there have been attempts to supplant it many, many times, it's the kind of code which solves problems but nobody fully knows what they are, and thus every attempt to replace it has missed features and ended up not fit for purpose. That the tool is unmaintainable, buggy, and slow? Well, so it goes.

Today's snippet is Perl:

my $query = "SELECT id FROM admin_networks WHERE id='8' or id='13' or id='14' or id='16' or id='22' or id='26' or id='27' or id='23' or id='40' or id='39' or id='33' or id='31'";
my $sth = $dbh->prepare($query);
$sth->execute or die "Error : $DBI::errstr\n";
while(my $id_network=$sth->fetchrow_array()){
    my $query2 = "SELECT name FROM admin_routeurs where networkid='$id_network'";
    my $sth2 = $dbh->prepare($query2);
    $sth2->execute or die "Error : $DBI::errstr\n";
    while(my $name=$sth2->fetchrow_array()){

        print LOG "name : $name\n";
        print FACTION "$name\n";
    }
}

Now, I have to be honest, my favorite part of Perl is the or die idiom. "Do this thing, or die." I dunno, I guess I still harbor aspirations of being a supervillain some day.

But here we have a beautiful little bit of bad code. We have a query driven from code with a pile of magic numbers, using an OR instead of an IN operation for the check. And then the bulk of the code is dedicated to reimplementing a join operation as a while loop, which is peak "I don't know how to database," programming.

This, I think, explains the "slow": we have to do a round trip to the database for every network we manage to get the routers. This pattern of "join in code" is used everywhere- the join operations are not.

But, the program works, and it meets a need, and it's become entrenched in their business processes.

[Advertisement] ProGet’s got you covered with security and access controls on your NuGet feeds. Learn more.