Use LabView with style
The LabVIEW Style Book, by Peter A. Blume, Prentice Hall, 2007. 372 pages. $89 in hardcover or $64.08 in downloadable PDF format.www.prenhallprofessional.com/title/0132414813.
LabView, like all programming languages, gives you the opportunity to write functional but unmaintainable code. Because LabView is a graphical language, you can write code that truly resembles a plate of spaghetti.
Peter Blume, president of Bloomy Controls and a top LabView programmer, has seen his share of LabView spaghetti code. In this book, Blume shows you how to avoid code entanglement. He gives many examples of clean and messy code and states, though a series of rules, how to develop easy-to-read code. Chapter 1 provides a roadmap of the book where Blume provides examples of both clean and messy code. He follows up with a chapter that, although not LabView specific, explains why you should carefully plan your software project.
For more comments on this book, see my blog.
Have you read this book? Post your comments there, too.
The meat of the book starts with chapter 3 where Blume covers user interfaces. The examples he uses show how to build panels that are easy to read and use. He shows good and bad user panels and stresses the need for simplicity and consistency in the use of fonts, colors, and object grouping. Many of the examples apply equally to other programming languages that let you build custom user panels.
Chapter 4 delves into LabView specifics. If you’re a LabView programmer and read just one chapter in this book, then read this one. Here, Blume shows you how to apply his many rules to streamline your block diagrams. He uses side-by-side examples of clean and spaghetti code that perform the same function, yet one is far easier to read. You’ll learn rules that apply not only to LabView programming, but to drawing of any schematic such as parallel lines, equal spacing, left-to-right data flow, and minimal bends. Blume shows how to use nesting and sub VIs to simplify code and he stresses the need for comments.
Chapter 5 covers icons, which LabView uses to indicate functions, operators, and sub VIs. Here, you’ll learn conventions that can help you and others identify the functions contained within the VI represented by the icon. For example, Blume stresses the use of color and symbols to differentiate and identify the function of code within an icon.
Software for instrument control and data acquisition generates a lot of data, and chapter 6 shows you how to choose the best data structure. For example, don’t use an alphanumeric string to represent an integer--you’ll waste memory and run the chance of introducing data errors. Plus, you open the door for users to enter data in the wrong format. As in the other chapters, Blume show you the right way and the wrong way to represent data.
Chapter 7 covers error handling and chapter 8 pulls together chapters 3 through 7. Here, Blume covers how to develop code that’s not only readable, but efficient. He covers how to use, but not overuse, programming tools such as state machines, loops, and shift registers. He uses the same example, a torque hysteresis VI, implemented with state machines and event machines.
Because no good program is complete without documentation, Blume dedicates chapter 9 to that purpose. He does, though, mention documentation throughout the book. He mentions rules such as “Leave notes for the development team” and “Label each note in the left corner.” By following these and other rules, you’ll not only produce understandable code, you let others know where to find points of information.
Blume wraps up with a chapter on code reviews. He describes processes and tools you can use to review and analyze your code. He advocates using the LabView VI Analyzer toolkit to help you automate your code analysis.
The LabVIEW Style Book provides many rules and examples that you can apply to your programs. Other LabView style guides have been published over the years, but Blume’s is the most comprehensive. It’s well worth the money for any LabView programmer.