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

[crossrulz]

I've never heard of the over-use of case structures.  The only thing I've seen with case structures that I would deem almost unreadable is a case structure insides of a case structure inside of a etc.

But I'm glad you hit on two of my annoyances: Locals and Globals.

I avoid local variables very well, but there are some cases where you just need them (two different states in a state machine need to update the same indicator, for instance).  But my annoyance (and turned into my pet peeve) was way back when (probably about 8 years ago) when there was just a huge mantra "Do NOT use local variables."  So, being the smart people my coworkers were, they said "Ok, not allowed to use local variables.  Hey, we can use Value property nodes instead!"  It was an interesting day when I gave a presentation on why that was worse.  Never saw so many wide eyes.  Needless to say, we saw a lot more use of shift registers and queues after that day.

The Globals argument has been beaten to death in the forums.  So I'd rather not get into that.  But I use globals, mostly for Write Once Read Many setups.  They do have their place.  But aim for dataflow first.

[swatts]

The case statement thing has occured a couple of times in the last few weeks (currently as part of the comments to the 5 Rookie Mistakes thing doing the rounds). Maybe it's an OOP thing and branches should be done by method calls or some such.

I don't really get it, that said, just because I don't get it doesn't make it wrong. Maybe there's an excellent reason.

I find Locals, used correctly, improve the readability of the block diagram. Computers nowadays can handle the extra burden for me (that is their job after all and I'm paid more than them)

I know I'm being contrary but it's not done us much harm.

The key things in SSDCs' coding standards revolve around readability and certainly not on prohibiting the use of some of the tools in the palette.

[Elijah_K]

One of the reasons people limit cases (and the number of unique case structures) is because they're trying to demonstrate that their code has a finite number of execution paths that can be tested. There's actually an industry standard metric for this: cyclomatic complexity (VI Analyzer can generate this number for LabVIEW programs).

This metric basically gives you a number, and the larger the number, the less testable the code is. Some organizations actually set hard limits on that number and require that functions demonstrate that their cyclomatic complexity is under a defined threshold.

Every decision point essentially causes this number to get bigger and parallel execution paths with unique decision points can cause this number to balloon quickly since you'd have to define test cases that exercise every possible combination of decisions.

Anyway, not saying it's common, but that's one of the only reasons I could think of.

Cheers from across the pond,

-e

[swatts]

Thanks Elijah,

It's a sign of (my) age, I did check out cyclomatic complexity and then it dropped out of my head. Think it's because it's got the word complexity in it.

I think you've nailed it though, but it get's ugly not because you have many branches in 1 case structure, but many branches within branches within branches. We don't have many issues with our cases so I need to dig back into past designs to find a suitable example and what we do to negate the issue.

I think it may be to do with our use of enumerated operators (forcing a clear decision path) or our restriction on complex logic. I'll have a dig, because this is really interesting to me.

My simplistic/gut feeling is that if you are using the case structure to model a state machine with 15 states then that is just what it is, jumping through hoops to remove states to obey a set of arbitrary rules will cause more problems than it will solve.

Nice to hear from you

Steve

[swatts]

I'm going to hold my thoughts on cyclomatic complexity for now. It's an interesting subject....... Will chip in if we get some more comments.

http://en.wikipedia.org/wiki/Cyclomatic_complexity

[Pie566942.0]

Thanks Steve and Jon for another thought-provoking read.  I always enjoy your ramblings.

I feel if a design requires a case/switch/if-then-else/etc. then so be it.  Software has to make decisions, and we know that's unavoidable.  If you nest three case structures with Boolean selects, you have eight code paths to test.  If you refactor the design to a single case structure with an enumeration case select (eight items, undefined items not allowed), you have eight code paths to test...One caveat being you may have complicated the design and wasted your customer's money by forcing an unnatural design.

The key difference in my experience, is it tends to be easier to read and test all eight paths in the refactored design.  We certify our LabVIEW SW using a text-based test executive.  To test the nested design, I write three nested loops.  To test the refactored design, I write one loop.  I've long-ago parted ways with NI UTF, but I could make the same test analogy with NI UTF.

To the readability point, I'm a huge fan of the structure labels and subdiagram labels.  If there's the slightest chance someone will inherit your LabVIEW code in the future (maybe even yourself!), these labels should be turned on and used.

Regards,

Steve K

[swatts]

You beauty Steve,

I knew if I held my council someone would put it better than me!

Pie566942.0 wrote:

                       

Software has to make decisions, and we know that's unavoidable. 

That completely nailed my initial response.

I notice that the cyclomatic complexity metric description ends in a LOC discussion, sadly it may not tell you anything more than you have a complex problem to solve. Where LOC tells us that we have a large program.

I'm not dismissing it out of hand because the pathways through a program may be the important factor. I'm thinking how nested decision branches might give issues equivalent to complex logic. I just have a niggle that this has bitten me in the past.

Case statement labeling has been a major improvement for us over the last few years, it makes you think in words about the logic you are applying.

Thanks Matey, you going to NIDays?

[Beutlich]

Case Structures and Stacked Sequences can be annoying not just because of the increased complexity they carry, but how they hide their complexity.

Hidden code can enable overlooking elements, so when I see a stacking structure like a Case Statement, I have to brace for unknown quantities of code in each new diagram. If there are embedded stacking structures in the VI, it can easily begin to feel like the plot from Inception (what layer are we on again?).

This is not really a performance issue, but a stylistic one. Case Structures are the perfect tool for the problem they solve. Most of the pain comes from some scenario like a new developer mapping every if-else statement in C++ code to a telescoping Case Statement. With a little restructuring, these VIs may be able to remove Case Structures entirely, which is preferrable for the developer maintaining the VI later.

Similarly, local variables and global variables are harped on because they are easy to get wrong by new developers. If I'm accustomed to thinking about text based code, I expect to have a handful of variables I can access anywhere in a certain scope of code, and sequencing that access is implicit. A new LabVIEW developer is only exposed to a few tools, and local variables seem like the closest fit to this model. Without care the new developer can easily create race conditions that are not obvious, and race conditions are a notorious 'ghost in the machine' problem. Warning signs about local variables encourage new developers to think twice about how to make the most effective use of data flow.

[AristosQueue (NI)]

When we say "globals are evil", we really do mean "globals," not "nuanced usage of data storage well understood by advanced architects." It is a mantra that we teach to most users, and it is a good mantra.

And race conditions are only the most egregious problem. When a value can be changed anywhere in your program, it makes it very hard to figure out which part of the program was responsible for setting it to a bad value. Globals make it very hard to run two instances of your code or to recursively call a subroutine. They are a major encumberance to refactoring.

> This annoys me because it takes a pretty standard software

> design issue and makes it LabVIEWesque.

It is hardly unique to LabVIEW. Unscoped data causes issues in every programming language, to the point that there are entire programming languages built around not allowing global data ever.

Even sealed private inside a .lvlib, global VIs are frequently problematic.  Frequently they generate far more data copies than are strictly necessary. If they are used for any purpose other than write-once-at-launch, then they have strange states that need to be accounted for.

The vast vast vast majority of the time that a programmer reaches for a global, he or she should be reaching for a wire -- a wire that will pass into the subroutine the data that would otherwise come from the global VI. Are there times when a global VI is the right solution? Sometimes. Are those very infrequent to the point of non-existent for most programmers? Yes.

You may not understand the admonition against globals because you successfully use them. Many programmers across many generations used them successfully. But far more programmers across those generations ended up with programs that were nearly impossible to debug. Scoped data was the solution, and in LabVIEW, that means wires.

[swatts]

Very much appreciate your input! it very clearly describes the thought processes involved.

Compared to various clever techniques used to obfuscate and confuse me, sequence structures are a minor aggravation. Isn't the real problem unreadable block diagrams.

The part I'm struggling with is how a case statement can hide complexity. I'm still trying to dig an example from my memory where nested case statements have made a project get away from me and how it was refactored to improve matters. It's niggling me!

I'm not against warnings, in fact I was only suggesting last week that techniques taught in LabVIEW Training courses should be taught in more clinical fashion (i.e. rather than just teaching a method and showing it's advantages, also describe the sacrifices).

What I'm really against is the blanket statements with nothing to back them up. It seems to me to go from a marginal annoyance to a taboo as it's passed from "expert" to "expert".

The other thing is that writing this stuff into coding standards inhibits me from developing code in our proven technique, a technique that causes no real problems for us and anyone looking after our code and has allowed us to successfully deploy >100 projects. Just because an expert has declared an absolute taboo.

Our code review document has an item to check and then a description to why it is important to us. Justifying the review item really improves the document IMO.

[swatts]

Evening Mr Q

I'm being very contrary about Globals, we know full well the danger of global data and use it very sparingly. My issue really is that by stating simplistically that the reason not to use Globals is race conditions is actually a red herring. Global data shouldn't be used because global coupling makes your design hard to debug. This seems much more important than race conditions. There are a million and one analogys that can be used to back this statement up. That's why I included the McConnell quote, because I think that is the line that should appear in training.

[AristosQueue (NI)]

I've taught too many CS courses in my life and tried to help too many new users come into LabVIEW. Is it a simplification to say "never use globals"? Yes. Is it a valuable simplification? Yes, in my opinion.

Globals are addictive. They're easy. They reduce the work, both physical wiring and mental strain, involved in planning out and implementing a piece of software. And if students have that shortcut in their mental toolbox, in my experience, it is very hard for them to think of the better solution. I've seen programs that use lots of globals and if I query the author, I often get a laundry list of rationalizations about how good they are and why this is a great use for them, but it is really just covering for not wanting to run a wire from A to B.

We ALL get sloppy sometimes. It's a pain in the ass to properly wrap an API. It is annoying as hell to wire a value down through N layers of VI hierarchy to get it to the one place that you need it. It's easy to say, "Look, I'm just going to stash it over here and use it down there." As programmers who have done this for years, we at least feel guilty when we do it. New users, not so much... well, not until they can't debug or can't refactor.

It's like chocolate. You can either tell a kid, "No, you can't have any unless I say you can" or you can hand them the chocolate bar and explain how they should eat it sparringly. For some kids, I tell them to eat it sparringly, but that's not common.

[ohiofudu]

Well said Mr Q "We ALL get sloppy sometimes. It's a pain in the ass to properly wrap an API"

[drjdpowell]

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).

With shift registers one can bundle all state information into a single shift register and use "Unbundle by Name" to give the same readability.  An advantage of the shift register is that it is private to one loop, and can't be used as a form of inter-loop communication.  Using Locals for data shared storage accessed in parallel is what can be problematic.

[AristosQueue (NI)]

I'll use local variables for updating user interfaces, but I try to never use them for passing data in my code... definitely I would avoid using them to share across frames of a state machine. That access is serial -- no concern about parallel access -- but they're still bad choice, IMO.

First, you still have the problem of remembering to clear your variables at the start of your routine. Shift registers may not remind you to initialize them by breaking the subVI, but at least they're sitting there and you think, "Oh, I should wire that with an initial value." With the local variables, there's nothing on the diagram that makes you think, "Oh, I should add a giant sequence structure around my entire code and add a frame before it where I set all these locals to some sane value."

drdjpowell talks about bundling all your values into one cluster. I'll happily take the separate shift registers! They provide very efficient access to data. With the "linked tunnels" feature of LV 2009, I don't have to slow down to wire them across in new cases. And for readability, it's like a musical score -- lines go straight across when at rest and bend down to be modified when there's notes... er... nodes... to be played. Read only values are easily recognized -- they go straight across with just a forked wire hanging down.

Then there's subVIs. Try to convert some code that uses a local variable into a subVI. What do you get? Refnums. Defeats a lot of the goal of making a subVI. It doesn't help you share code, and it isn't independently runnable, so you *still* need a caller to test the subVI.

And then there's the probe issue. Those shift registers? I can put probes on the space between the case/event structure and my loop boundary and see the value every time. With local variables, I have to fill in lots of probes in individual cases. That makes it much harder to figure out who is setting the value wrong. Swatts asks the question comparing local variables to data through shift registers or references. Local variables *are* references. Static references, yes, but references none-the-less. You cannot follow the wire to see the data changes. I'll grant that at least local variables provide an easy way to find all the use locations with the Search Results, rather than tracing the refnum wire. But I'd rather trace a dataflow wire than the Search Results dialog.

I didn't even get to the data copies that locals create on read -- often very inefficient, especially if your data is waveforms, strings or arrays. Or clusters of those. LabVIEW could introduce a more efficient local variable, some control that cannot be accessed through VI Server so the code of the diagram could be analyzed to determine that a copy of the variable doesn't need to be left in the variable. But we haven't, so they are always a copy on read.

In short... there are very good uses for locals, but passing data isn't one of them, in my opinion.

[swatts]

Beautifully put Mr Q, that is exactly what I wanted from this discussion, an educated discussion about usage. If I could like your post twice I would, I might create another account just for that purpose.

(I have to admit we posted the article to provoke a reaction, if not quite a troll article, maybe one with an impish spirit, we're such scalliwags)

I agree with your local usage whole-heartedly, we use them pretty much as you describe. I have never once found any performance issue with using them, although it is stated often, I'm guessing RAM has outstripped it as an issue for 99.9% of applications.

btw I find the search results dialog to be very useful (the ticks tell you where you have been, which is very handy indeed)

[AristosQueue (NI)]

> I have never once found any performance issue with using them

Shows up with the large arrays/waveforms, mostly.

It also showed up for one customer. He wanted help with the performance of his app. No one ever showed him shift registers. As a result, before every loop, in a sequence structure, he wrote to local variables. Inside the loop, at the start, he read the local variables. At the end of the loop, he wrote to the local variables. After the loop, he read the local variables to get the final value.

Every loop.

The saddest part about his code is that it worked. If it had broken, he might have asked someone sooner. As it was, he just had one heck of a performance issue.

[swatts]

I think there is a similar issue with globals, they are so damned easy to use and fairly efficient too. It makes doing the right thing much more difficult!

[pretech]

What a lot of confusing stuff! I'm at the labview rookie-with-some-experience stage, but this thread has me wondering just how I am "supposed" to pass data around!

After all, if all variables are banned, then all block diagrams must end up looking like a plate of spagghetti bolognaise!

If you can't use variables, what is the "right" thing to use?

Oh, yes! The value property node! Well silly me! But that is banned too! As well as having performance issues!

How about FGV's? Anyone got a problem with them? Apart from the fact that you need a new VI for each piece of data!

I have just finished replacing occurrences in a project with notifiers. I did this because I was having

issues with "ignore previous", and notifiers have the ability to be reset. And they can carry data!

Perhaps they are the answer!

Seriously, though. Surely there is a place for all the different types of variable.

The big problem is the lack of quality information on where to use and to not use each.

Especially when you have to pass data through multiple VI's and sub VI's.

[Thoric]

Pretech: have you considered the LabVIEW core 1,2 and 3 courses? There's good collated information in there on when the pros and cons of each data sharing strategy.

[swatts]

perceptive post pretech, I'm not really into prohibitions and as you can  tell from my other posts I don't really go with the flow. Here's my advice...

Lots and lots of wires (especially references) around your block diagram are an indication of a lack of cohesion in your design. We collect like functionality together into 1 SubVI and hold the data that would be shared privately. This cutting down of data flowing around your diagram solves a lot of issues (encapsulation).

We don't use property nodes to pass values, although value (signalling) is pretty useful.

FGVs, Globals, Named Queues, Notifiers are all forms of globally accessable memory and should be minimised or scoped (Coupling). The reason being is that it makes your program more difficult to debug, unpredictable in it's actions and brittle in its design. With Globals writing once, reading many times is a pretty good rule.

We have never used notifiers or occurences in our code. (there are use cases where they are needed, but we've never needed them)

LabVIEW is a dataflow language but not all data has to flow!. You really don't need to view everything, in fact you only want to see what is being actioned at that particular time.

The concept of dataflow time is actually a reasonably powerful design concept. IMO Local variables are better than wires for documenting code when they are applied in short phases of dataflow time. In an event or message handled by a QMH for example, generally if bounded by a Case statement or Event Case. Where they cause issues is if they are placed floating in a large bit of code that spans a lot of dataflow time.

The point of the article was to cause a bit of confusion and to get people to think about the design aspects of LabVIEW rather than just trot out hackneyed prohibitions.

In the comments are some very good justifications and reasons from my marvellous commenters (your comment included) and they pretty much explain the whys.

When I get a moment I'll put up a block diagram and point out where I'm breaking rules and my thoughts for doing it.

As designers we need to understand why we bend rules/guidelines and the justification for doing so.

For me the biggest crime that you can do to LabVIEW is to make it difficult to read.

Appreciate the input

Steve

[James_McN]

I'm realising "Performance Issues" is really a bad term to use in a general context.

It is thrown around as an absolute measure where really it is a relative term, if my computer takes 1 second to update a display is that a performance issue? It's slower than if I reduced the data, faster than drawing in paint.

The question is what performance is required and what are the trade offs that can be made. That is the art of designing software rather than the science.

Whether it is a useful term to avoid misuse while people are learning their trade, I spent enough years doing tech support to respect that viewpoint!

[swatts]

There is more science to it than is given credit James, although if you watch this it is surprising how difficult to understand and explain it is https://www.youtube.com/watch?v=hd0v72pD1MI.

These are renowned industry experts and watch them struggle to agree/explain coupling and cohesion. (Kent Beck is the creator of Extreme Programming and Test Driven Software development)

My worries about teaching in a prohibitive manner is that the guys teaching it are not necessarily experienced enough to put it into context. I'm an awful student and if you tell me not to do something with a good reason why, guess what!. If you give a bit of context then it starts to go in.

And bending your code into strange shapes just to avoid using a local variable is counter-intuitive to me.

Your performance comment is spot-on, guessing you're doing fixed price jobs now! Acceptable is fast enough

[drjdpowell]

pretech wrote:

After all, if all variables are banned, then all block diagrams must end up looking like a plate of spagghetti bolognaise!

If you can't use variables, what is the "right" thing to use?

                   

I use Messages, and queued message handlers, mainly.  One queue (or User Event or whatever) wire per handler.  Different data is packed in different messages.

In general, more advanced architecture has fewer wires running arround (though those wires are often clusters or other more complex datastructures) and most wires don't travel very far.   This is one of the reasons that the more advanced LabVIEW types disdain "variables" or "wireless" techniques; they don't really need them.

[pretech]

Wow, what a lot of responses! Thanks to everybody for commenting (including AristosQueue's PM) especially as I stumbled across this thread while looking for something else!

To give some background from where I'm coming from. I started my current job about 6 years ago and prior to that I had never heard of Labview. I work for a very small design and developmant company (My boss and me!) which uses Labview in some of our projects. My boss is self taught, and I am too, while picking his brains when possible! Since then we have done between us 5 labview projects. So I am not using Labview all the time, only when the need for it come up.

And so far all of my projects have been for in-house use, so as long at it works, and in the Labview environment, that's OK.

But now my latest one looks like it may be sold, so I'm now contemplating the practicalities of that, deploying on different computers, OS's etc. It's a bit intimidating!

(Oh, for easily scalable front panels and controls, but that's another story!)

But I really like using Labview, although at times I could throw it out the window!

My background is not in programming, so the graphical nature of Labview is great for me.

drdjpowell, I'm intrigued by your use of queues. Must experiment with it!

[swatts]

We like the discussion, probably searching for something that cannot be found..

Queues are well worth exploring. They are fast, powerful and intuitive. Hats off to the developer (stand up Aristos!!)

[AristosQueue (NI)]

pretech wrote:

But I really like using Labview, although at times I could throw it out the window!

                   

Me too. 🙂

[pretech]

Well, I couldn't wait! Thank you drdjpowell for talking about using queues!

I've now hashed up two VI's working transferring data both ways using a queue of 1 element, a cluster.

And one of the cluster elements is a stop signal so I can close one VI from the other!

It seems to be a very elegent solution to data transfer, but I feel it's a bit over the top for

some places. And I suppose that it could still be subject to race issues in some cases.

I'll be looking to making some changes to my current project! Getting rid of hidden indicators which are only there to create a variable from seems like a good start. I wonder how many other rookies do that.

[AristosQueue (NI)]

pretech wrote:

                       

I wonder how many other rookies do that.

                   

Many unless they go through the NI customer education courses.  This is why with LV 2013 LabVIEW introduced the project templates on when you create a new project, in the hopes that more of this information would get in front of customers.

LabVIEW makes it possible for people without training to program amazing things, but training still helps make those amazing things even better.

[swatts]

With regards overuse of case statements it appears that our position is now backed up by some science. In the study titled "Some Code Smells Have a Significant but Small Effect on Faults" in the ACM Transactions on Software Engineering and Methodology Vol 23 No4 (Aug 2014) that the Code Smell "Switch Statement", pertaining to replacement of case statements with polymorphism, has no relationship with faults.

I know how to spend a Saturday evening (although I was also watching "The Raid 2")