Once upon a time I owned a cool domain name: www.crappycode.com. My intention with that site was to create a forum to allow developers to upload code they'd encountered in their day-to-day operations that qualified as truly crappy code. Other developers could then come along and rate code on a badness scale (maybe it would have a few points like managebility, scalability, intelligibility, etc). I sadly let the domain lapse, and a camper seems to have picked it up... and is asking a few $k to acquire it. Even though I no longer have the site, I've still made it a practice of collecting HORRID little snippets, and the other day while musing through them I found one that is sure to have been a winner.

Of course, it's fair to say that we all grow/improve as we write code... or at least those of us that care do. There's another subset of developers that clock in, pound away, and clock out. It's these developers that I like to lovingly refer to as developers whose only tool is a hammer. We've all cleaned up after them, and it's quite clear in our minds that all of us would be a lot better off if these people would just find another career path. What's worse is when you come across code written by somebody whose 'only tool is a hammer' and it appears that they're holding the hammer by the head and pounding with the handle... the following code definitely falls into that category.

     Here's the evidence:



Note first of all that this thing was set to run EVERY DAY the hard way (i.e. somebody clicked on each day of the week (in blue) instead of simply clicking the single radio button : daily (in red).

    Now for the code:

set rowcount 1000
delete from
TableWithLotsOfRows
where EnterDtTm 
   < (cast(cast(cast(getdate() as float) as int) as datetime)) - 100

I have no idea what they were trying to accomplish here. First of all, there's no need to cast to be able to subtract an integer from a datetime... the SQL Server folks made that one work implicitly. In other words the above WHERE clause could have simply been written as:

WHERE EnterDtTm < GETDATE() -100.

It is arguable that MAYBE the creater of this code wanted to 'round off' some aspect of the datetime through the casts... but that argument doesn't really wash because if they wanted such precision... why bother limiting the DELETE to 1000 rows Or maybe they were just confused and didn't think you could subtract an integer from a datetime If that were the case (even supposing you had to cast a datetime to a float before you could make it an int)... the code would still look like:

WHERE EnterDtTm < CAST((CAST(CAST(GETDATE() AS float) as int)) AS datetime)

In the end, the code worked, at least it deleted things and didn't throw errors.. and I guess that when your only tool is a hammer, that's good enough (which is very sad).