Your LabVIEW Code Is a Work of Art... But I Can't Read It

[Darren]

We often talk about LabVIEW programming style: rules to follow to make VIs "look good". We assume LabVIEW code that follows style guidelines is well-written and easy to read. I propose there is a palpable gap between style and readability, and I can prove it by creating and reviewing several beautiful VIs... that are unreadable. In this presentation I introduce simple programming techniques you can follow to maximize the readability of your LabVIEW code.

The slides were last refreshed in July 2024.

You can watch a recording of the presentation here.

(bit.ly/labviewreadability redirects here)

[PhillipDBrooks]

[Darren]

Now when somebody views this link with a preview, the image shown is your meme. Thanks, Philip.

[AlanA.]

Hi, I am also code readability/aesthetics freak.

You are totally right about readability of data getting in and out
I would have done readable and noisy section this way:

Even though the lines break I find it to be more clean, especially when I consider a "functional expansion" of this situation.

I mean inserting another processing sections which are driven by other type of main data, if that makes more sense.

I could've been ranting about evolution of this code and its positioning and style for hours but I don't want this entry to be an essay 😄

Would love to know your thoughts on 1st picture.

[Darren]

> Would love to know your thoughts on 1st picture.

Looks perfectly readable to me, you've just prioritized keeping the class wire straight instead of the error wire. I don't have strong feelings on that preference, I know other LabVIEW programmers do.

[avogadro5]

I disagree entirely on not wiring class outputs through - and not on the basis of prettiness. A major point of OO+dynamic dispatch is that you don't know with certainty what will happen when the VI is called when you are writing the caller - maybe the specific implementation will want to maintain some internal state that gets updated between calls. You just made it impossible to do without using a reference type! In order to maintain some semblance of the OO functionality you get in other languages - namely a guarantee to a single state per class "instance" - I always follow the convention of maintaining a single dataflow branch for each "instance."

[Darren]

All of my LabVIEW class in/out terminal discussion refers to by-value classes. If any child implementation of a dynamic dispatch method has the potential to modify the class value, then of course you need an output terminal. The reason I advocate selectively adding class outputs is to aid in debugging, where you can more quickly narrow down which methods actually modify the class value when you don't stick an output terminal on everything.