Zombie SQL

, 2018-11-12 (first published: )

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

Rate

Share

Share

Rate

Related content

Database Mirroring FAQ: Can a 2008 SQL instance be used as the witness for a 2005 database mirroring setup?

Question: Can a 2008 SQL instance be used as the witness for a 2005 database mirroring setup? This question was sent to me via email. My reply follows. Can a 2008 SQL instance be used as the witness for a 2005 database mirroring setup? Databases to be mirrored are currently running on 2005 SQL instances but will be upgraded to 2008 SQL in the near future.

2009-02-23

1,567 reads

Networking - Part 4

You may want to read Part 1 , Part 2 , and Part 3 before continuing. This time around I'd like to talk about social networking. We'll start with social networking. Facebook, MySpace, and Twitter are all good examples of using technology to let...

2009-02-17

1,530 reads

Speaking at Community Events - More Thoughts

Last week I posted Speaking at Community Events - Time to Raise the Bar?, a first cut at talking about to what degree we should require experience for speakers at events like SQLSaturday as well as when it might be appropriate to add additional focus/limitations on the presentations that are accepted. I've got a few more thoughts on the topic this week, and I look forward to your comments.

2009-02-13

360 reads