TLA, FLA, FLA, SLA, SLA, ELA

A long time ago in a Company that wrote telecoms software I remember having a discussion that ran along the lines of

"So the SMSC sends an SRI to the HLR, which returns the MSC, Then we Send the SM to the MSC which queries the VLR....."

The conversation went on in that vein for some ten minutes as we discussed where exactly the problem was, what was not talking to what and why not.

To anyone without very current domain knowledge, it was Dutch, or Latin, or perhaps Cherokee, but either way it was hard to follow.

Our code would have been a nightmare for someone to try to follow, it was littered with variable names which were TLAs, FLAs and *FLAs, and some times they were context dependent.

In this day and age, most editors have variable name completion, and **memory is not an issue, so for the love of peace and harmony, and for the sanity of the new guy who starts on Thursday and has to try to figure out the code and fix bugs in it, with partial domain knowledge, and incomplete documentation, at least give the variables and functions sensible names.

(*FLA = Four Letter Abbreviation, unless it has been preceded by FLA, in which case the latter FLA means FIVE Letter Abbreviation)

(**I did work on a program ones, where I had to change all the variable names to shorter names to save memory. That was a long, long, long time ago, when 8k was a whole world of ram, and the program was stored as text, and continually interpreted, and goto was 2nd the most common keyword after if.)

Unit testing is hard....

The main reason that unit testing is hard it that it requires many of the things that good design requires.

Built in dependencies

It’s much easier to hard code things, strings, external dependencies, statics and so on. It’s more effort to coordinate gathering up the various external requirements for a class in a sensible place, and then pass the external requirements on to that class.

 

In c# for example it is easy to have a class directly call:

 

featureEnabledString = ConfigurationManager.AppSettings["EnableFeatureX"];

 

Of course, now in order to run unit tests, you need an App.config.

 

And if you want to write a test where that feature is disabled, you need to get creative.

Perhaps you set up a derived test class to set the value of base.featureEnabledString so that you can test the thing that needs testing.

 

That’s all well and good for adding tests to existing code, but now, you are testing your derived test class, as well as your production class.  And they are more or less the same but not exactly the same. (That’s a pretty good definition of a bug, it’s more or less the same as I what I want, but not exactly.)

 

Complexity

As you class starts to do more and more things, it gets harder and harder to manage the testing.

As the complexity of your class goes up, and internally a, b and c all interact together, it gets harder and harder to manage testing.

But the underlying problem here is not testing the class. The fact that the class is becoming harder and harder to test is a really good indication that the class is too big and too complex.

If you can’t test it, it’s probably too complex to work in the real world too.

If you need to set up 20 different things to get a test to work, it’s probably too complex to work in the real world too.

 

Don’t shoot the Messenger

The unit testing is not the problem. It’s just bringing the bad news. Your code needs some reworking, refactoring, rethinking.

Zapping the unit tests, checking it all in leaving the mess for someone else is more befitting of an elected representative than a Software Engineer.

The class within

If you are ever working on a class, and it seems like a good idea to group a few functions and member variables together, stop.

Right about now, you have just reached the point where you should seriously consider breaking out the functionality into a separate class.

Of all the times I've looked through code (including my own code), I've usually had unkind thoughts about the author of classes that were too big. I don't often remember thinking "why did he bother creating a class for that?"

return bool

someFunction(true, false, false, true);


or


someFunction(Sensor.Enabled, Filtering.Disabled, Normalising.Disabled, Smoothing.Exponential);


I know which one is 

• easier to read
• easier to debug
• harder to get wrong when you call it
• slightly more effort initially.