Just like with any programming language (especially one that is used in as many different countries and on as many different computing platforms as LabVIEW) there’s no substitute for good programming style. Style helps programmers write better code that is easier to use, maintain, and review. Since LabVIEW is quite different from other programming languages it isn’t always easy for new users to adapt to the best coding practices. I have been using LabVIEW for 6 months now and I am still learning all of the features designed to improve the quality of a LabVIEW program.
This article reviews 3 mistakes that I personally made the most while I was starting with LabVIEW. For a more extensive list of common mistakes made in LabVIEW please follow this link.
1. Overusing Flat Sequence Structures
This is a mistake I personally made a lot when I first started using LabVIEW. It was because I did not fully understand the concepts behind “dataflow” execution, which is fundamental to LabVIEW programming. One indication of this is that users often overuse the flat sequence structure on their block diagrams. Users often rely on flat sequence structures to force the serial execution of code on the block diagram, instead of using the flow of data with wires between nodes. If you want to learn more about data flow in LabVIEW so you can better understand when you should and shouldn’t use flat sequence structures check out this link.
2. Misusing Local Variables
Another common mistake in LabVIEW programs is an overuse of local variables. Local variables are a piece of shared memory used to pass data between different sections of a computer program. Commonly used in text-based languages, variables can be very empowering, but can also lead to problems when a race condition is encountered.
Unlike other programming languages where passing data through variables is essential, LabVIEW provides the dataflow method of moving data from one part of a program to another. The parallelism inherent to LabVIEW makes overusing variables problematic because shared memory is often accessed by different code locations at the same time. If this happens, one read/write operation wins the “race” and the other loses. The losing data operation is forgotten, so overusing variables in LabVIEW can ultimately lead to lost data.
3. Disregarding the Need for Documentation
Trying to discern what a program written by someone else does is helped greatly by good code documentation. Unfortunately, documentation is normally left until the end of the development cycle after the functionality is complete. This leaves little time to document code properly and trying to understand poorly documented code can be a nightmare. Instead, time should be carved out during development to start the documentation process. I have found that making personal notes on my code as I go helps a lot too, you would be surprised how much you can forget after a few days of not looking at your code.
Thank you for reading my blog post, and for more information about common mistakes in LabVIEW follow this link. If you are interested in trying out LabVIEW for yourself, you can purchase a copy of LabVIEW 2014 Home Edition which includes everything you will need to run LINX 3.0. Please comment below with any questions or comments you may have.
