A Rant about FGVs

[swatts]

There is a popular misconception that the LCOD methodology described in our book ("A Software Engineering Approach to LabVIEW") is in some way related to FGVs (Functional Global Variables). This is because the construction of what we call components is superficially similar. i.e. you have an enumerated command, permanent data held internally to the VI (usually in a shift register). This has been used as a stick to beat us with and IT ENDS HERE!!! (to use a Hollywood cliche).

First of all let's take a look at a classic FGV...

This is no different than doing this with globals...

Or this in OOP....

I could carry on with different ways of storing and accessing data globally, but I have to earn a living.

So why is this a bad thing?

Global data in software is bad because it is Common coupling.

Common coupling (also known as Global coupling) is when two modules share the same global data (e.g., a global variable).

If a lot of VI's are poking around in the same data space it becomes hard to predict what the program is doing, hard to maintain and hard to read. In short it ends up a difficult to debug, inflexible and confusing mess.

How does our methodology differ from this?

We clearly state that a component should have local memory that is private, so while you can make access to the data public (as you can with OOP) it's not a good design idea.

We use the term components, others use the action engines but they are not FGVs!!!

Code Smell #2: Too much global data.