In LabVIEW programming, a common practice is to pass data structures—such as references, clusters, or classes—through SubVIs, even when these SubVIs only consume the data without modifying it. This approach maintains a consistent data flow, making the code appear orderly and aligned with traditional LabVIEW design patterns.

However, this practice can obscure the SubVI's actual behavior. When a data wire passes through a SubVI, it's not immediately clear whether the SubVI modifies the data or simply reads it. This ambiguity can complicate debugging, as developers may need to inspect each SubVI to understand its effect on the data.

An alternative approach is to avoid passing the data wire through SubVIs that do not modify the data. By doing so, the block diagram provides immediate visual cues about which SubVIs are purely consumers of the data. This enhances code readability and aids in debugging, as developers can quickly identify which SubVIs might affect the data state.

While this method may initially seem untidy or counter to established conventions, it offers practical benefits by clearly delineating data consumers from data modifiers. Adopting this practice can lead to more maintainable and understandable LabVIEW code.

In summary, reconsidering the necessity of passing data wires through non-modifying SubVIs can improve code clarity and debugging efficiency in LabVIEW applications.

For more details, refer to the original article on the DQMH Consortium blog: "Just Passing Through". and the presentation of Darren An End to Brainless LabVIEW Programming

• Improved Readability: Clearly shows which SubVIs modify data and which do not.
• Easier Debugging (Time saving): Reduces debugging complexity and developer frustration.
• Better Maintainability: Simplifies understanding of data flow.
• Visual Clarity: Cleaner diagrams with distinct consumer and modifier roles.
• Parallel Execution Benefits: Avoiding unnecessary pass-through wires can enhance parallelism and execution flow.
• Dynamic Dispatch Compatibility: Dynamic dispatch VIs work effectively with just class inputs, without requiring pass-through wires.

• Breaks Convention: May appear untidy compared to standard LabVIEW practices.
• Learning Curve: Requires adjustment for developers accustomed to traditional methods.
• Perceived Complexity: Deviates from consistent data flow patterns, potentially confusing newcomers.
• Additional Effort: Need to explicitly document or structure non-modifying SubVIs.
• Future Interface Changes: If the VI later modifies class/cluster data, its interface may need to be updated to include outputs, creating potential rework.