Brainless LabVIEW Programming: CLA Summit 2016

One of the presentations I attended at this years Certified LabVIEW Architects Summit was given by Darren Nattinger of National Instruments. Darren is a Principal Engineer in LabVIEW R & D. One of the many things he’s responsible for is getting the Quick Drop feature added to LabVIEW. His presentation was titled, ”An End to Brainless LabVIEW Programming”.

 It was a very informative and entertaining presentation.

So what is “Brainless” programming? Basically anything we do because:

• We’ve always done them that way
• We’ve been taught that it is a “Best Practice”

Darren covered 8 things even seasoned LabVIEW programmers frequently do without thinking. These items may go against “conventional wisdom” when it comes to LabVIEW programming. Here are 3 of the items with the conventional logic behind the action and a brief overview of the reason not to do it.

1. All SubVI’s need an Error Case Structure
   • Conventional thinking
     • Ensures subVI code never executes if there is an incoming error.
     • Currently the norm in most subVI template VIs, like class accessor VIs.
     • Currently assessed when taking the CLD exam.
   • Reasons against the conventional thinking
     • Any time you can remove a decision point from a diagram, it opens up all sorts of potential compiler optimizations
     • Just about every new error ends up being generated by built-in functions. And almost all of them no-op on an incoming error. So why don’t we let them do all the work
     • You can optimize for the error case (with a case structure) or the non-error case (with no case structure). Errors are usually the unexpected condition, so you should optimize for the non-error case
     • If your diagram is performing custom error handling, then use an error case structure around its contents so that code doesn’t run (and potentially mess with an incoming error)
2. Avoid Global Variables at all costs
   • Conventional thinking
     • Globals are evil!
     • They can be easily abused!
     • They lead to race conditions!
     • Never use Globals!
     • Use functional Globals instead
   • Reasons against the conventional thinking
     • Globals are just one tool in a big tool box
     • Global variables are very easy to use
     • The safest way to use them is to write to them in 1 or fewer places.
     • Don’t brainlessly replace them with read/write functional Globals. Same exact functionality, but take longer to implement
     • Darren has written a separate blog post on this topic and it has some good discussion in the comments
3. Always Close all References
   • Conventional thinking
     • If you get a reference, close it when you’re done.
     • It’s a commonly accepted best practice.
     • Easiest way to avoid memory leaks.
   • Don’t worry about closing these references
     • Anything  that inherits from GObject (it’s actually a no-op!) including static control references.
       
       
     • “This VI” and “This Application” static references
       
     • Outputs of implicit App and VI property/invoke nodes
       
   • Always close these  references
     • ActiveX/.NET/hardware
       • For ActiveX/.NET, you usually need to close the references in order, from child to parent, once you’re done with them.
     • App/VI that are explicitly opened or obtained from properties/methods
       
     • ProjectItem
     • Project

I think the main point Darren was trying to make is always be thinking about what you’re doing and always be trying to improve your code (and code practices).

 If you’re interested in reading through the entire presentation, it can be downloaded here.