This is a post I have been wanting to write for a long time, not to share some technical nuance or promote some new product, but because of the philosophical debate that I hope it promotes. It is something I have wondered about for several years, and my viewpoint on it has shifted several times. In fact, my opinion has recently changed again. It’s time to talk to others and get some consensus of opinion.
So diving straight into the issue with a rhetorical question:
Is it good LabVIEW programming practice to pass a reference, cluster or class through a SubVI if that SubVI is only consuming the data and not modifying it in any way ?
There, I’ve said it, now discuss!
Before the floodgates open, let me explain my reason for asking the question and put my point across. Consider the image below:
This is something comfortable and familiar. Something that we are used to seeing daily in our LabVIEW code; a common thread being passed amongst members of a library, or in this case a LabVIEW class.
However, looking at the code above it’s not obvious what (if any) action the Write DB VI or Read User VI is performing on the class. Is it writing data to the class, consuming data or both ? If I am experiencing problems related to the data in the class not being as expected at a later point downstream, then I need to dig inside each VI to see what it’s doing as part of my debug process.
Inside the Write DB VI I see the following:
As you can see, we are simply consuming the data, accessing the class data and writing it to a database. The passing through of the class is not required and yet what happens if we don’t do this?
I may be stuck in my ways but this looks incomplete, and the calling code “looks” even worse!
Now, I’m nothing if not pragmatic.
Let’s take a step back. Neat and tidy it may not be, but the diagram above conveys significantly more information. I can now see at a glance that the Write DB VI is merely a consumer of the data. If the values in my class are incorrect, I know that I don’t need to look inside that VI to find the cause. I have now improved the quality of information described by my block diagram and let’s not forget that this is the reason why we use LabVIEW in the first place. I have made debugging easier, and as much as it sets my OCD on high alert, that extra junction in the wire tells me what I need to know.
I don’t like it (but could probably get used to it)…..however “pretty is as pretty does”.
Does it matter what the class private data consists of? If the class contains references such as a VISA refnum, does this affect the decision to pass through data?
Again consider the following construct:
We have no idea how the Reset VI is operating upon the class. We need to look inside to see if it is modifying the private data.
The rebuilding of the VISA refnum and the passing through of class data is redundant, but the alternative makes me somewhat uncomfortable.
Some of this discomfort goes way back to when I was first getting started with LabVIEW, when my college Professor had the mantra “wire every Serial / GPIB reference through EVERY VI.“ This guy would literally pull the power lead out of your PC if he caught you not doing this. Maybe I just got tired of re-booting Windows 3.1, but the message stuck.
Speaking to others who have run into issues with virtual COM ports and the like, the concept of not wiring a reference straight through makes them nervous; it’s like a comfort blanket for them.
So now it’s over to you to consider the following:
Is it more or less readable to pass the class through? What do we mean by readable anyway? Are we talking about “form over function” here?
As we have seen, not passing a wire through a Sub VI can actually provide more information, but it goes against the common style that most of us are familiar with and which is promoted in countless example programs and by NI themselves in their training manuals and style guide documentation.
I’d love to hear your thoughts on the matter, so please leave your comments.
…and by the way, whether or not you should actually use the error case structures in the examples above is a topic for another blog post.