Blame it on Flowchart

[In all these postings, I will use "she" for the person who coded and "he" who is maintaining it. Any inference on compassion from "coder" to "maintainer" is irrespective of the genders used here.]

Remember the days when they tought to draw flow charts in the school?

That tool "un-tought" us to think simple. Here are the reasons:

It tought one less way of logic:

Flow chart had that diamond shaped decision block with three-way exit points. Now, I don't have any problem with three ways – "yes", "no" and "error". That symbol could imbibe error handling in our habits.

However, for some reason, our teachers never tought on possibility of an error and having to write error handler for the piece of code.

Usually the conditions inside such a diamond is a combination: "If the file pointer is not NULL and the file pointer reads EOF", "If the pointer is not null and the structure member of that pointed address has some value".

There are 3 cases involved:

  1. This situation needed action. The file pointer reached EOF or the desired member had desired value. Almost all of us code this part correctly.
  2. The situation needed some other action or no action. The file pointer did not reach EOF or the desired member did not have desired value. Most of us code this part also correctly.
  3. Interestingly, there existed third situation! The file pointer was NULL. I find most of us are out of oxygen then – specially while maintaining other's code.

Most of the books showed us two paths – "yes" and "no". But there existed a possibility of accident!

Typically the programmer who wrote the code (and whom you are searching to choke to death) "conveniently ignored" the error situation. That is because none in her school tought her that a real life flow chart typically has more than two exit points!

So our maintainer now starts thinking of methods to handle the error in a code that never had the concept. This, my friends, is next to impossible task. So the code starts complicating.

Programming decisions are typically like Ganga. They are "tri-patha-gaa" – go three ways – error, yes and no. So respect their sanctity.

[OK! I shall talk about the puritanical way of "only two way decisions" later.]

School wanted us to Mark "y" or "n" on the Decision Branch:

You won't believe this. I lost grades on marking the following legend and following it in one of the programming papers:

"All downflowing branches of flowchart decision blocks mean 'yes' and all sideward branches mean 'no'."

Why should we program 'if' and also the 'else'? Take for example, the problem of setting defaults.

The problem is: set x to 1 if y is 3 else x is 5.

Most of us flowchart in our mind:

  1. (Is y 3? create two branches, mark one with 'yes') write an 'if' statement and assign x to 1.
  2. (now what happens to the 'no' branch?) put 'else' clause and assign x to 5.

That is not how human being (maintainer of your code, if you consider him human) is going to think when he analyses the problem!

He arrives at the module – and has assumption about behavior of x. He is going to seek under what conditions x's value changed.

I repeat, he is not interested in "how x's value changes under different circumstances". He is interested in "under what conditions x's value is what".

Thinking like him, a simpler program would serve much better:

/* default values */

set x to 5

/* alter x based on y */

if y is 3,

set x to 1

What is the advantage? If y never turned 3 in maintainer's life, he would never even look at the condition!

That makes his life very dull and bore. He does not need to draw truth tables to find out where x got modified.

There was No "switch-case" Symbol in Flowchart:

The diamond is a *wrong* but the only symbol to represent enumerated decisions in flowchart. (Once again, I was penalized in grades in the school for inventing my 6 way star as a flowchart symbol.)

Most of my friends never developed a habit of thinking in terms of a switch-case in part because of this limitation of flow-chart and the fact that they could "map" flow-chart symbols to programming constructs.

They were tought "whatever can be flow-charted, can be programmed" but they misconstrued it as "whatever can not be flow-charted can not be programmed".

Many a time you see a ladder of "else if"'s. If you collapse all the code inside, you will be surprised to see it is nothing but a switch-case.

Then what is wrong with equivalent "else if" ladder? Isn't it as fast to execute? In most cases.

But think of it as an unfolding story before the maintainer. He is not there to read her soap opera. Once again, when the maintainer enters the code, his sole aim is to get out of it as soon as possible. The only question in the mind of the maintainer is:

"What matters to my problem?"

A switch-case is near ideal way of letting him skip the areas that don't interest him. He jumps to the case that the problem at hand describes – rather than on wondering whether his trace could have been caught in one of those intermediate "else-if"s.

This also prompts me in wondering why all the code editors I used were almost never collapsible. If I am not interested in a code branch, I should be able to close it like Windows Explorer in tree view.
Coming back to the point, think of the ladder again. You would also have noticed a lot of code in braches repeats. [ In OOP, this code is a candidate for the base class. ] This shows careless coding or coding done over times.

Such coding can not improve with switch-case enforcement. However, once the code is "split in logical parallels", relationship between lvalues with the switch parameter become very apparent. Often, some smart, 2 line way of replacing 50 lines of switch startles.

If you are doing structured programming, using switch-case in all reasonable (and some unreasonable) circumstances will help you in structuring your code better.

Flowcharts don't Effectively Represent Recursion:

Recursion is not something you are likely to come across if you are not parsing or handling trees.

I have seen code like:

foreach of nodes in output of ls

foreach of nodes in output of ls ofits subdirectories

foreach of nodes in output of ls ofits subdirectories


And the code had a limitation of "shall not allow more than 3 levels of subdirectories". We paid it through our nose to that contractor!

The person was so obsessed with flow, he simply missed the recursion!




Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s