CODE Smell: if not EASY and not SIMPLE or not UNDERSTANDABLE=COMPLEX LOGIC!

[swatts]

One of the traps graphical programming can spring is that sometimes the elegant and fun interface can lead you into bad design decisions.

A common one for me is tinkering with logical decisions until I end up with something like this...

I sometimes view the block diagram as a conversation between you and another developer (and as Fabiola De la Cueva asserts, it's good to think of this developer as a psycopath who knows where you live). Now the conversation for this bit of code goes something like.

IF (OpenCCT Detected NOR SOC Detected)

AND

((Keyswitch=Remote AND Source NOT=RT Localhost)

OR

((Keyswitch=Local AND Source=RT Localhost))

OR

(OP Power Setpoint=0)) THEN do something..

I can envisage Fabs psycopathic developer reaching for his axe sharpener.

So what are the alternatives when complex decisions are required?

I personally prefer words and nested case statements using enumerated types.

It's more readable and less likely therefore to have errors. These 2 statements are related!

Some people prefer look-up tables, decision matrices etc etc. I suggest these should be implented using a single VI with all the inputs brought in. A test-stub can the be used to exercise all the combinations. The output to this VI should be an enumerated type describing the decision made.

Code Smell#3: Complex Logic  

Code Deodorant: A Case should be described by one simple sentence that can have 1 AND or 1 OR in it. Where possible use words rather than boolean or Maths to make your decisions.

The other thing that commonly causes issues in code is negative logic.

The human brain is a positive thing generally, negative logic causes problems in understanding and therefore bugs.

Code Smell#4: Negative Logic  

Code Deodorant: Right-click on the case statement, bring up label, and write the logical description for the TRUE case. This simple thing has saved me hours of head-scratching and improved my handling of decision making.

Also avoid NOTs etc where possible.

Lots of Love

Steve

ooh pithy quote....

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.

— Brian W. Kernighan and P. J. Plauger in The Elements of Programming Style.