Reclaiming Refactoring

We need to talk about refactoring. Or rather, about the frequent misuse of the word, the dangers this encompasses and what we can do about it. Time to reclaim what is an intrinsic part of software development!

As with many words in the English language, people use the word refactoring for different concepts. It’s a human thing to do, but it keeps surprising me how open for interpretation most terms are in a “scientific” field like computer science. Just try to Google an exact definition for the concept of a unit test: you’ll find about as many interpretations as there are people writing about it.

Legacy code retreat

Have you ever worked with code that literally brought tears to your eyes? Not in the good sense, mind you. I’m talking about code that is such a hassle to work with it makes you rethink some of your career choices. If that’s the case, a legacy code retreat might be just what you need to stop your fear of legacy code and instead start to appreciate the opportunities for improvement it provides. Legacy code can be a joy to work with, if you tackle it the right way.

Who do You write code for?

TL;DR: You should write code in a way that your colleagues would understand best. After all, they are the ones that will be reading it over and over again. No matter in how much of a hurry you are, you should always take the time to give things meaningful names.

Who do you write code for? It’s a simple question with an obvious answer.

As Martin Fowler bluntly states it:

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

The days of a programmer writing cryptic assembly code that only their computer understands have long gone by.  The question deserves attention however, as I seem to keep bumping into examples that prove not everyone shares this belief (or is too lazy to act upon it).

The example

Recently, I came across a bit of SQL code that looked like this:

DECLARE @nvcWFN_SQL NVARCHAR(MAX)
DECLARE @nvcWFN_SQL_1 NVARCHAR(MAX)
DECLARE @nvcWFN_SQL_2 NVARCHAR(MAX)
DECLARE @nvcWFN_SQL_2Bis NVARCHAR(MAX)
DECLARE @nvcWFN_SQL_2Bis2 NVARCHAR(MAX)
DECLARE @nvcWFN_SQL_2Bis3 NVARCHAR(MAX)
DECLARE @nvcWFN_SQL_3 NVARCHAR(MAX)
DECLARE @nvcWFN_SQL_4 NVARCHAR(MAX)
DECLARE @nvcWFN_SQL_4Bis NVARCHAR(MAX)
DECLARE @nvcWFN_SQL_4Bis2 NVARCHAR(MAX)
DECLARE @nvcWFN_SQL_4Bis3 NVARCHAR(MAX)
DECLARE @nvcWFN_SQL_5 NVARCHAR(MAX)
DECLARE @nvcWFN_SQL_6 NVARCHAR(MAX)

--The code goes on by initializing these variables with parts of
--a SQL SELECT query

SET @nvcWFN_SQL =
        @nvcWFN_SQL_1 + @nvcWFN_SQL_2 + @nvcWFN_SQL_2Bis +
        @nvcWFN_SQL_2Bis2 + @nvcWFN_SQL_2Bis3 + @nvcWFN_SQL_3 +
        @nvcWFN_SQL_4 + @nvcWFN_SQL_4Bis + @nvcWFN_SQL_4Bis2 +
        @nvcWFN_SQL_4Bis3 + @nvcWFN_SQL_5 + @nvcWFN_SQL_6

--Execute the dynamically generated query
EXEC sp_executesql @nvcWFN_SQL

This is part of some code that generates a complex SQL query at runtime. Ignore the fact that this might not be the best idea ever, but just analyze the code itself.