If Then Else

One thing I have learned over the years in software development is that its usually either A) the problems you don't foresee or B) that quick, last minute change that's totally obvious that causes the most problems.

A lot of things that I work on tend to have long lifetimes.  This is good because it generally allows me to have a sustained business relationship as well.  On the other hand things that I had worked on say, five years ago, are much less obvious today than they were at the time.  I have also learned to be very careful not to "second guess" what I was thinking at the time.

So recently a customer from another country asked me to make a change to a system that had been in production for a couple of years.  The system is large and complex and controlled by some XML configuration files.  I have a duplicate system here so I was able to work through the requirements, modify the XML configurations files, and test the results.

With that completed I had to transfer the edits I made locally to the XML provided by the customer that was in use for their system - which I did.

The only problem was that I only saved some of the changes into the file.  I made all the changes but inadvertently forget to hit "save" on last time. 

Of course it was my intention to save the file before copying it to email - but I didn't check it completely.  The first few edits made it but not all of them.  When I opened the file to check I saw the first edit or two (as they were near the top of the file) so I assumed the rest were there.

Another thing I have discovered over the years has to do with the concept of if-then-else.

When working on programs you will often write code that looks like this:

  if (A) then B

This seems simple enough.

But as time has gone by I have discovered a few things...

For one, most programming languages allow B to be several statements.  Usually they are grouped by special characters, e.g., '{' and '}' that mean do all of the grouped things.


  if (A) then { E, F, G }


Again it seems simple enough - in this case E, F and G are all processed if, and only if, A is true.  Otherwise none of E, F and G will be processed.


Over the years, though, I have found that I should write this:

  if (A) then { B }


even if there is only B to perform if A is true.

(I get flak for this from other programmers.)

However, what I have discovered is that during the ensuing years after code is written you often come back and add things, e.g.,


  if (A) then { B, C }



So my idea, which works well, is to always assume that there will be more to do if A is true and to always write { B } even though I could write just B.

The reason is that later on, usually years, I will need to add something that needs to happen along with B but I will forget in my haste that the form without '{' and '}' only allows one thing to be the consequence of A, e.g.,

   if (A) then { B, C }

means if A is true do B and C.

  if (A) then B, C 

means if A is true do B and always do C regardless of A.

Not the same thing.

You might say "well, that's just your own fault" - and it is.  But consider this.  Usually when I am creating a software product I have a lot of time to do it - time to carefully consider what's going on.  In later years, during maintenance, I am make changes at the behest of a customer.

This means I am pressed for time because often there is some production work being held up and some new work that cannot be done without the change.

So its easy to be less careful and make foolish mistakes in haste.

Adding the '{' and '}' makes it easier to get things right later.

Its always completely clear were what is done as a consequence of A starts and ends.