One thing that I try to do when writing LabVIEW code, is to craft it in such a way that it breaks during just the right editing circumstances. I know that it might sound crazy, but it’s true.
You probably know that LabVIEW is a very strictly typed language. For example, when you try to wire two dissimilar data types together, the wire breaks. This is the LabVIEW editor telling you that the requested operation will not work. Now, aren’t you glad that LabVIEW tells you this while you’re editing the code, rather than when you’re running it! What if LabVIEW waited until you ran the code and then, only when the data flowed into the differently typed wire, a crazy error message popped up that said “runtime exception: illegal operation converting a Boolean to a cluster” (or something like that). And, what if this error didn’t show up until the code was shipped to the customer! Yes, LabVIEW’s strict typing is a great thing.
We can also use strict typing in clever ways that are not exactly obvious. One great way that we can use this behavior is to tell us when a code maintenance task is not complete. Here’s an specific example: let’s say that you have three types of hardware that are defined by an enumeration with values Serial and TCP-IP. In your code you have this enumeration wired to a Case Structure that switches between the two different frames — each frame handling the respective communication mechanism. And then, one day your customer calls you says that they just heard about this great new technology called Bluetooth and they just have to have support for it in their code. And you, being the agreeable developer, say, “Sure thing. I’ll add that right away.” So, you go and modify the enumeration, adding a third value called “Bluetooth” and you’re done, right? Of course not, now you have to go modify every location in your code that relies on the value of that enumeration to do the work of communicating via Bluetooth. But, where do you begin? You recall that you have a read function and a write function, so you go in there and you add the code. Are you done? Maybe, but maybe not. How do you know? Much much testing should you do? Do you ship the code?
What if there were a way to know every location where you need to add code to support the new Bluetooth functionality? Well, there is a way. Simply write your code in a way that, when elements are added to the enumeration, something causes a break in your code in exactly the locations where you need to add new code. For example, if you have the enumeration wired into a Case Structure’s case selector terminal. If you define a default value for the case structure, then the default frame will automatically handle it. However, if you ultimately intend to add one case for every enumeration value, then what you have is a bug. If you had not defined any default case, then your case structure would have broken and LabVIEW would have shown you the error messages shown, below. This would mean that you would be able to let LabVIEW show you exactly where you needed to do the necessary changes to your code.
So, write your LabVIEW code so that it breaks on just the right occasions.