So here I am doing some maintenance on a legacy reporting web app.
I am used to there being some awful, nasty, WTFish code - but the kind of things I find never cease to surprise me.
The point of this page is basically to select data from a table where the ID is x, and the date range is between Y and Z using a stored procedure. So you think the stored procedure would have three parameters... no. It has 16. SIXTEEN.
The page lets you select a few different options for date - range, exact date, past 6 months, all data, etc.
Instead of converting all of those to a range within the page itself on POST it instead lets the stored procedure do the work. Fine - I guess it works, so whatever.
So after that the procedure sanitizes the data that was already sanitized from the page. This is fine, we deal with sensitive data so extra precautions aren't a bad thing.
Then the guy declares a new variable... @sql. No, I cannot even believe he's about to do this shit. He isn't, is he? He's building a god damn query string within the stored procedure that's going to get executed. WHY?
And then this giant string of query breaks off randomly... and then uses a giant block (10, not including above sanitation) of if statements to determine what he's selecting because he decided to declare 16 different fucking parameters.
And that kids is how you turn a 5 liner into a 166 liner. Hooray for beast servers that can handle this kind of shit.
Consistently awful code that still surprises you
Started by Guest_ElatedOwl_* , Feb 16 2012 11:50 AM
1 reply to this topic
Posted 16 February 2012 - 11:50 AM
Posted 17 February 2012 - 01:07 PM
As someone who has worked with SQL daily for at least the past 3 years... I have never seen something that needed SIXTEEN FUCKING PARAMETERS. What the shit tinsel.
Rumors of my demise have been greatly exaggerated.