Leave Code in the state you would like to find it in.

It’s been one of my principles since I started being an independent developer. Much of my work is maintaining old codebases, and there are many horror stories that I could recount.

The temptation is there to do a quick-and-dirty modification, a quick patch, but one should resist the temptation.

Customers generally do not understand the concept of refactoring and I have to this date never been able to persuade any customer of parting with cash for refactoring. Arguments about less work down the line just fall on deaf ears.

So the refactoring is included in my normal style of coding – on-the-fly refactoring, if you will. I generally find that it’s well worth refactoring badly written code as you are trying to read it.Renaming variables is my first step at reading the code, then creating subfunctions that have a clear purpose in separate functions. If the code is complex I’ll generally do the step of converting it to object-oriented code. It might seem like a waste of time or even overzealousness, but on the long run it’s well worth it, also for your client, for his maintenance costs are going to go down.

So, whenever I am within a function that I need to update or correct, I make sure that I leave the code in a state that won’t make me cringe. This usually means renaming variables (naming them for what the content is, not the container – i.e. docPurchaseOrder instead of doc), adding error trapping, and deleting stuff.

I love deleting stuff. The fewer design elements, the fewer functions there are, the better, if you ask me.

In the past, if you were a Notes developer without access to third-party tools, coding was very much an accretive process. Need a lookup view? Create a new one. Need a slightly different function? copy-paste. Since we had no visibility about dependencies, it was really dangerous to remove things – so the convention was just to add things.

Over the years this results in a terrible mess.

Thankfully there are some tools one still can use. One of my favourites is Teamstudio’s lscalls, a small exe that lists out functions that are no longer called by any other function. This is a really powerful and safe way to identify functions ready for deletion.

Teamstudio no longer posts it on their website (too legacy-ish, presumably) but they will send you the file if you e-mail them and ask nicely.

Just for me, here is an example of the syntax.

C:\Program Files (x86)\IBM\Notes>lscalls “C:\Program Files (x86)\IBM\Notes\Data\Development\eFSR\eFSR3_0\Efsr_(3_0)_Field_Service_Local_Dev.nsf” -o “c:\temp\lscallsoutput.csv”

You will need to place lscalls.exe in your notes program directory.

A little caveat: if a function is shared between multiple databases with inherited script libraries, you might want to make a check on all databases sharing the common code.