Easy on the Case (Part 1)

No matter how you learnt how to program, using whatever language, you did learn how to use branch structures: If/Else/Elseif, Switch/Case, Case... This structure allows you to write code that works very fast, because it reflects the way we, humans, make decisions in our daily life. Coffee or Tea? Bus, car, bike or walk? TV show or movie? Classy shoes or casual sneakers? After all, we are who we are as the result of an endless series of "branch structures."

When an engineer needs to design or describe a system, this approach easily translates into state-based languages such as Grafcet or other diagram flowcharts. If I'm lazy (a current state) and it's sunday (a parameter), then I would use my phone and order a pizza (two future states), and based on how long it takes (state output), I can choose what to do in the next 30 minutes (a future state). Repeat.

Yeah right LabVIEW developers haven't reinvented the wheel: we all use the state machine design pattern, with plenty of (nested) case structures. Everywhere. Now, abusing this structure quickly leads to this:

Minimize the number...

I remember one of the most experienced engineers as I was learning LabVIEW when he told customers and junior engineers: "Don't write octopus VIs or applications." The octopus is a neat image! Imagine yourself, or your project manager, or your customer, asking for the simplest addition/extension to that feature you are working on today. You'll say OK, and you'll add another case, or another structure—loop, case structure, other—that handles this. You'll add another tentacle to the core of your octopus VI. Be careful with the number of tentacles! An octopus without tentacles is useless, but a 15-tentacled octopus is confusing, slow and subject to more health problems/bugs.

You possibly want to write tree code instead. Most of the time a new branch grows on a strong existing branch, not directly on the trunk. This fosters cohesion in your code—a VI should execute one specific task— and offers more modularity in case you need to use this new "branch code" on another strong branch of your tree.

...And maximize the efficiency

Sometimes, trying to optimize the most basic operations like comparisons seems worthless. "You don't want to spend 5 minutes overthinking it for no apparent result", they say. But sometimes it's vital (LabVIEW FPGA!). Once you've been forced to do it a few times, you may develop a kind of optimization superpower! Try some of these by yourself today, and I promise you will earn much more than 5 minutes in your LabVIEW developer career (readability, performance, scalability, simplicity...)

Use range features in the case selector value field: "..0" for inferior or equal to zero, "1..9" for between one and nince, "2.." for greater or equal to two... It not only works for numerical but for enums and strings!

Use coma-separated selector values instead of duplicating subdiagrams code.

Make insensitive string matches by right-clicking a case structure based on a string input. A small overlay in the bottom left corner of the frame will appear.

Combine multiple boolean conditions into an integer, or use the compound arithmetic node.

These are common tips that you can use everyday to reduce the number of case structures or subdiagrams. You won't get rid of all of them as your code needs them to distinguish a variety of behaviors based on a set of input values. But that's good enough for now!