Programming from habit

During an advanced driver training lesson, I was approaching a roundabout on an utterly empty dual carriageway, I could see all entrances and exits were completely clear of cars, lorries, cyclists and pedestrians.

My instructor asked me to the first exit. So, I checked my mirrors, indicated, checked my mirrors again and as I completed the maneuver my instructor asked me why I had indicated.

Well, I had done it because it was a good habit to get into. Let the world know your intentions before making a turn. It's in the highway code and part of the police "system", right?

My instructors reply was quite the eye opener. His reply was that I should not do anything in the out of "habit". Every action behind the wheel should be thought about, planned and assessed. Had I gone through that when applying the "system" to my approach to the roundabout I would have made a conscious decision - is there anyone who will benefit from my signal? No, so lets decide not to. It's a decision based on the current conditions and, had a vehicle appeared while on approach then the "plan" to apply would be to consciously decide to switch the turn signal on.

This level of consciousness and speedy decision making behind the wheel takes concentration and practice. It's worth while though because it makes you a much safer driver and generally you get from A to B quicker, smoother, within the rules of the road and much more relaxed.

This same level of consciousness applies to programming.

When I am doing code reviews I often see the same constructs appearing time after time as the programmer habitually does things. My example of the day is habitually testing a variable has a value before using it in a function call.

A good habit - that makes sure your error logs are not full of notices and warnings about trying to do something on "null". It's also a habit that can lead to bloated and overcomplex code. Conditional statements become long and cumbersome to read - purely because it is habit.

If we stop and think we can often simplify our code - and simple code is the best code. It tends to be faster, less bug prone and when we come back to it later so much easire to read.

The real habit it so question. What would happen if I use null here? What happens if what the variable is not an instance of a particular class? Will it "make noise" in the logs or trigger a fatal error. Or does it not matter at all.

So, is it worth checking a variable is null if we are also going to check if "trim" returns an empty string? Answer is no it's not, so our habit of testing for null first is only going to bloat the code. Try it in a scratch file... trimming null returns and empty string.

Is it worth checking if a variable is of an iterable type brfore passing using it in a "foreach". Answer is yes, because if you do not you will at the very least get an unnecessary notice in your logs if not a rick a fatal error.

Is it worth doing a count before trying the foreach? I would say it is not. If the variable is empty then it will loop zero times.

There are many other defensive programming habits that are actually counter productive simple because we do it out of habit and do not think about the implications. We rely on it simply being best practice.

So, lets understand our every action, be it behind the wheel or behind the keyboard. Best practice is to know and understand exactly what we are doing and decide on the correct actions in any given individual situation.