Zombie SQL

2

October 31, 2018 by Kenneth Fisher

It Halloween so time for a scary SQL story. Ok, maybe not that scary. Ok, not scary at all, but still a bad practice. It’s Zombie code so it seemed like something fun to talk about on Halloween. But what is it?

 
Zombie Code

Code that is left in place but commented out.

At least that’s the best definition I was able to find. You’ve seen it right? Those big queries left in the stored procedure but commented out? Or lines of the WHERE clause commented out? Heck, I’ll bet you’ve done it. I know I have.

“I might need that code later.”
“That was pretty cool, I’ll save it so I can look at it again.”
“I just don’t like deleting code if I don’t have to.”
“It’s not working, I’ll comment it out and come back to it later.”

The problem is, zombie code is distracting. It makes it harder to read what’s actually going on, and as you learn to tune it out, you are also learning to tune out the real comments. And comments are important.

CREATE PROCEDURE ReallyImportantBatchProcess AS

SELECT ReallyImportantColumn1, ReallyImportantColumn2, 
	ReallyImportantColumn3, ReallyImportantColumn4
	INTO #ImportantToday
FROM ReallyImportantData
WHERE ImportantDate = Today;

/*------------------------------------
                       (()))
                      /|x x|
                     /\( - )
             ___.-._/\/
            /=`_'-'-'/  !!
            |-{-_-_-}     !
            (-{-_-_-}    !
             \{_-_-_}   !
              }-_-_-}
              {-_|-_}
              {-_|_-}
              {_-|-_}
              {_-|-_}  
          ____%%@ @%%_______
------------------------------------*/

-- [¬º-°]¬
ALTER TABLE #ImportantToday ADD Column Meh bit

UPDATE #ImportantToday SET Meh = 1 /* Did you see this? */
-- WHERE ReallyImportantColumn3 = 74

Now to be fair, when you are in the middle of development it can be perfectly reasonable to leave bits of code commented out. If it’s a personal script then I’d expect bits of commented code to expand the usefulness of the script. However, as code moves from development to test, and in particular when it moves past test into model office or even production, then all of that commented code should be removed. In the days of version control software, there is very little reason to leave bits of code commented out just so you can see them later and leaving code so it can be uncommented to add functionality shouldn’t be happening in production. The only comments that you want to leave in your code are the important ones. The ones that actually add value. That way when people scan the code, the comments jump out, they aren’t just part of the hoard of zombies.

Happy Halloween

2 thoughts on “Zombie SQL

  1. We’ve gone so far as to add this to the coding standards, and require that legacy code be cleaned up if it’s touched. Maybe you should write a companion piece on “Vampire SQL” – comments that don’t tell you anything useful but still distract you: such as “select results from temp table”. Um, duh…there’s the SELECT right there…

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Enter your email address to follow this blog and receive notifications of new posts by email.

Join 2,465 other followers

Follow me on Twitter

ToadWorld Pro of the Month November 2013
%d bloggers like this: