LabVIEW Taboos I don't understand

[swatts]

Hello my lovelies

This blog has not been nearly ranty enough lately, so.................

There's a lot of proscriptive recommendations in the LabVIEW world and some of them we struggle to understand, so keeping with our foolish nature let's have a closer look at them.

Over-use of Case Statements is Bad!

This is often trotted out and  WE JUST DON'T GET IT!

A case structure in LabVIEW is equivalent to a switch statement in C++ or Java, It's interesting to see if there are design restrictions on the number of branches handled in a single switch statement in these languages. A search didn't show much, this indicates that it's not a big issue in these languages. In fact the only issue was that in text based languages the statement becomes a pain to read through. Um not an issue with LabVIEW (although better filtering/navigation of the case structure would be a massive improvement).

We've even seen a company coding standard that limited the number of cases in a statement. Why on earth would you want to constrain your designs in such a way??

Local Variables are evil!

Rather than blandly inhibit their use wouldn't it be better to describe the situations where badly placed local variable cause issues (the "expert" says that Local Variables are bad lets just spread the meme without thinking about it). If you have a massive block diagram spanning a lot of LabVIEW dataflow time and you bung local variables into the free space you will probably get dataflow issues. Methinks the issue is not understanding dataflow rather than using local variables.

Our advice is to use Local Variables in bounded LabVIEW structures doing one thing only (short and sharp). So Event Structures, States and Queue driven case structures work fine in our book. That way you will read a valid local value, the diagram will be nice, clear and clean and if you have named your variables correctly it will help document your diagram too. 

So what is more difficult to understand a clearly labeled and named case structure with bounded local variables acting on this data or a load of complex logic, data wires through shift registers or references. (ducks out of way of the incoming flames).

Oooh the concept of diagrams spanning dataflow time!!!, maybe there is a seed of an idea here related to the physical aspects of a system.

Global Variables are more evil!

Again the proscriptive statements around global variables are "Global Variables are bad, they cause race conditions". This annoys me because it takes a pretty standard software design issue and makes it LabVIEWesque. It would be better to write it "Global Variables can cause problems because shared data is tight-coupling and this will cause unpredictable behavior". We've said it before but once again: race conditions are just one symptom of poor data coupling. We find global variables very useful, but we make them private members of an LVLIB and use a public interface to control access to the data if required (ideally it should stay in the bounds of the LVLIB). The real truth is that in a well designed system you shouldn't need global access to data.

"Two routines are global-data coupled if they make use of the same global data. This is also called common coupling or global coupling. If use of the data is read-only, the practice is tolerable. Generally, however, global-data coupling is undesirable because the connection between routines is neither intimate nor visible. The connection is so easy to miss that you could refer to it as information hiding's evil cousin......information losing"

Steve McConnell - Code Complete

Stacked Sequence Structures are like the goto statement in BASIC

no they are not!

The worst crime a stacked sequence structure is guilty of is obscuring some of your code. It's equivalent to using 5 pages rather than 1 long page, and actually the true crime is writing code that needs compressing in such a cumbersome fashion. It's never caused us a single issue with understanding the block diagram. Unlike goto statements which are a complete structural nightmare in text based languages.

Our coding standards do not proscribe tools or techniques but mostly concentrate on readability and simplicity.

On another note..

Function Points.....

We think this is an important exercise and we're going to ignore the lack of reaction to the article and plough on regardless with a manual trawl through an SSDC project and try and finalise a method for reverse engineering the Function Points of a project. This will include some VI Metrics, but we're trying to pull out just logical complexity. We will then try and automate the process. We've just got to do the hard miles first.

Lots of Love

Steve and Jon