m2oTech.com

  • Increase font size
  • Default font size
  • Decrease font size

Why reinvent the wheel?

Print PDF

It's a paradigma that has been gaining momentum recently, the Reduce-Reuse-Recycle can well apply to coding too. The more code we reuse the more efficient our application usually gets (in terms of "functions/hour"). It's no secret that most software on the market, be it commercial or not, is made up of building blocks (libraries, subprograms, ...) which considerably speed up the coding process. Why reinvent the wheel? Reusing existing code lets us focus on the functionality that matters, the features that are unique to our program. Often we reuse our own code from other projects, other times we take code from other developers, distributed under some sort of license (e.g. GPL for open-source software).

LabVIEW is no exception to this and provides through SubVI what other programming languages do with functions. These are (literally in the case of a graphical language like LabVIEW) the building blocks of complex applications. As manageability quickly decreases when a LabVIEW block diagram spans for more than one screen it is a must that other-than-trivial applications are broken down into SubVIs. Whenever we make a SubVI we should "think forward" and make it as general as possible, so that it can be reused in our next application... and then next one.

A few tricks to achieve this:

  • The name matters! Just like properly naming a function, a SubVI should also be named in a way that makes it easy to recognize at a glance what its functionality is. Better yet, the name should comply with a naming convention, at least within the same company/organization. For example arraySplit and arrayJoin or split_array and join_array, not at mix of the two.
  • The icon matters! Being LabVIEW a graphical language it is a must, that also the icon be used to convey the functionality, ideally before even reading the SubVI name. There is nothing worse than having the default LabVIEW VI icon for a series of SubVIs that do completely different tasks. A drawing convention is here a good thing too, for example we could use purple for VI that work with strings and orange for those who work with double values.
  • Whenever possible use only native datatypes, rather than custom types. There is nothing wrong with defining application-specific datatypes, it is indeed good practice. When it comes to making a SubVI we should however ask ourselves whether we really need to pass a custom datatype, or rather whether we could do that through a "wrapper SubVI", so that we can make the basic SubVI as application-independent as possible. Having said that, we can safely use clusters to pass data in and out of the SubVI, provided that these are well documented, if not self-explaining.
  • A good version control should also be in place, so that we always use the latest version of the SubVI in new applications (we may for example find and fix a bug or extend the functionality while using the SubVI).
  • Backward compatibility is in most cases of vital importance when making changes, as we do not want to break previous applications that are using the same SubVI. Alternatively we can create a new version of the SubVI and clearly label it.
  • For increased productivity we can create LLB (LabVIEW libraries) with VIs performing similar tasks. These can then be integrated into LabVIEW palette when working on the block diagram.

You will find a selection of ready-to-use VIs in our VIs section.

Last Updated on Thursday, 09 October 2014 00:43  

Add your comment

Your name:
Subject:
Comment:
  The word for verification. Lowercase letters only with no spaces.
Word verification: