T-SQL Tuesday #21: Crap Code
August 10th, 20114
T-SQL Tuesday #21: Crap Code
August 10th, 20114
 
 

Yes, Adam is right: we've all written crap code (the topic of this month's T-SQL Tuesday Wednesday). Usually we have an excuse: tight deadline, short shelf life of the code, or didn't know any better. I'm sure if I perused my career codebase I'd find tons and tons of examples that I'd write differently today, because back then it fell under one of these categories.

I've developed a lot of habits over the years. Mainly, these habits are better for me, but they're not necessarily better for everyone. I have my reasons for shifting my coding style in various ways, and I've documented many of them right here.

Some of those ideas revolve around readability and maintainability, and I don't ever expect to convince everyone else that commas belong at the end of a line, not the beginning, or that [column alias] = (expression) reads better than (expression) AS [column alias]. A lot of these are just preferences – as I've preached many times in the past, the conventions you choose are not as important as how consistent you are in implementing them and whether they make sense to you and those around you.

So when I look back at older code, I definitely see some things from my list of habits that have changed. Nothing important enough to go back and correct, but noticeable nonetheless. I see some dumb, wasteful things like this, where I'm building a ginormous dynamic SQL string and then either printing or executing the string depending on a flag. But then I add other junk to the end inside the conditional.

IF @debug = 1
BEGIN
    PRINT @sql + ' OPTION (MAXDOP 1);';
END
ELSE
BEGIN
    EXEC(@sql + ' OPTION (MAXDOP 1);');
    PRINT @@ROWCOUNT;
END

No, this kind of thing is not a big deal, and there are other things in there that I'm even more appalled at (one: not trying to remove the dynamic SQL in the first place, and two: using EXEC instead of sys.sp_executeSQL). But I'm pretty particular about tidy code and this kind of redundant string-building just irks me to no end.

Anyway, I don't want to focus on code, I just wanted to point out that you shouldn't be too hard on yourself for crap code that you've produced in the past. You probably had a good reason (or at least a lame excuse) for putting it out that way, and we all had to start somewhere. I only know a few people who think they've been an expert in their field since the day they were born; most of us will admit that we're always learning.

By: Aaron Bertrand

I am a passionate technologist with industry experience dating back to Classic ASP and SQL Server 6.5. I am a long-time Microsoft MVP, write at Simple Talk, SQLPerformance, and MSSQLTips, and have had the honor of speaking at more conferences than I can remember. In non-tech life, I am a husband, a father of two, a huge hockey and football fan, and my pronouns are he/him.

4 Responses

  1. AaronBertrand says:

    @Dizzy and @Kirby I've written about that as well (and included a search link in the post):
    /2011/09/17/bad-habits-to-kick-using-exec-instead-of-sp_executesql/

  2. Dizzy Dan says:

    ^^ what Kirby said

  3. Kirby Wallace says:

    Would be helpful if you would say why some of these things are not good.  Like, for instance, the difference between using EXEC instead of sp_ExecuteSQL().

  4. SeHun Kim says:

    This might be considered as "didn't know any better" category..
    At the time of writing the code, I would tap myself on my back saying, "dude.. this code is solid! This is AWESOME!"
    Then, a couple months later, I stumbles on the same code and like "WTF.. who wrote this shit!"  lol