P. Blume nailed it!!!!! I am a heavy user of LabView (aka "the View") and this guy absolutely nailed it. This may as well be entitled "the Joy of LabVIEW". I have learned more new positions and ways to get the best out of my partner (LabVIEW) than ever before. Let's just say after reading this masterpiece a cig and a drink were in order.

Kudos to P. Blume and the team at Bloomy Controls.

P. Blume nailed it!!!!! I am a heavy user of LabView (aka "the View") and this guy absolutely nailed it. This may as well be entitled "the Joy of LabVIEW". I have learned more new positions and ways to get the best out of my partner (LabVIEW) than ever before. Let's just say after reading this masterpiece a cig and a drink were in order.

Kudos to P. Blume and the team at Bloomy Controls.

I read the first couple chapters and was impressed with the quality of information. I then gave it to a programmer I am supervising for a project. I had him read it and told him to adhere to the standards of the book. After a couple weeks the code he is turning out is much improved. The flow is better, the code is documented and there is actual error control being used. It will be much easier to maintain the project as time goes on. The point of the book is to write better labview diagrams so I think it works quite well in that regards.

As the Title suggests "The Labview Style Book" only focuses on Style and provides no useful information outside the scope of the title.

For just a decade I've been dealing LabVIEW based system.
During the career, for almost all years I was stick to
narrowly inmatured programming style. So then unfortunately
sometimes I harmed my own career.

If I'd met this book earlier I were taking on the management
of a certain LabVIEW project. It's certainly a very regrettable
truth, but just becoming certified recently I'll go along
another career.

This is very helpful book, including GUI style and BD style.
It is important you should first have review in the data
structure and location of each objects in the diagram.
Various examples will guide you to the real world of LabVIEW.

Like to say thanks to the author.

I get the feeling the other reviews are written by the author and his friends.

This book is good but, needs editing because it is very long winded. He uses twice as many words than necessary to get the point across. Kind of funny since he stresses efficiency in block diagrams. Also, many of the "rules" are subjective and should be called suggestions. For example, the author has a rule disabling "Show dots at wire junctions". I like the dots.

I recommend the book but, be prepared to spend the time required for reading. In my opinion, LabVIEW GUI: Essential Techniques is still better.

The LabVIEW Style Book is the best reference book on the style and technique of developing solid maintainable LabVIEW. If you develop with LabVIEW, this book should be within reach at all times.

Until I saw this book, I was leery of using much LabVIEW. After reading it, I see that LabVIEW doesn't have to be a snarled mess, you can "write" very readable, and useful code. It really is a best practices guide for anyone who wants to write LabVIEW software.

then their efficiency would be much higher.

In our organization we have seen the classic LabVIEW evolution: People with little or no programming experience start with the 3 icon demo, and then start wiring like crazy, and soon are wired into a corner and have a spaghetti bowl of LabVIEW code.

People with Classic CS training may try to force object-orientedness down LabVIEW's throat, and end up having too complex, abstract structures, with a lot of overhead relative to the actual functionality.

Peter Blume's book is an excellent medicine against the above mentioned problems. Probably the absolute three most important rules is to always use Typedefs, choose an design pattern that matches your applications, and learn to use Queues.

Typedef is easy to learn, and should be taught the first day you learn LabVIEW. The time savings are enormous.

The choice of design patterns is a lot more difficult for beginners to intermediate programmers, because it really requires a lot of "wisdom" to pick the right one. Therefore, in my opinion, Chapter 8 is the most important chapter in the book, and also the Chapter that could benefit from even greater detail in learning why the shown patterns are used and going more into details about which things to avoid.

Once you have crossed that hurdle, LabVIEW becomes much easier, more efficient and fun. But for many the "best practice" design patterns seem to break the fundamental data flow rules you learn as a LabVIEW beginner.

* Front panel controls are handled in event structures (instead of being polled)
* Data and front panel controls are often accessed by reference instead of being "hardwired".
* Queues are a cool, safe, and efficient way to move data and control around between parallel loops, but may also confuse users because they also access data by reference, and hence could be considered to be "impure" in terms of data flow.

In addition, traditional LabVIEW wisdom says "avoid massive use of references", and avoid large hierarchical clusters. In my recent experience these rules seem antiquated, in that historical performance related issues with these don't seems to have a significant impact when running on modern machines.

I have also seen programmers who explicitly have avoided queues due to the difficulties associated with them in many textual languages.

In summary, the book is well written. Internally at DELTA we are in the process of adopting variations of Peter Blumes more advanced design patterns, which really are conceptually quite simple and clean, once you understand them.

One consequence about using these design patterns goes quite against the grain of certain ideas in classical programming, i.e. information hiding.

Typical object oriented LabVIEW code shows virtually no specific functionality at the high level. The consumer/producer design patterns in which functions and data are stuffed onto queues and de-queued in appropriate parallel executing loops, actually allows a lot of specific program logic to be visible at the top level, without getting cluttered.

This is thanks to the user interface being handled in case structures (at the top level) and resulting actions being fired (at the top level) in queue selected case structures in the consumer loops.

I have found this actually increases the readability of the code enormously, particularly if carefully lay out your wiring so that you create a Typedef of references to Queues and unbundle by name only the references that are used inside each consumer loop. Thus the master control logic is concisely represented at the top level, even though the diagram is relatively small.

Compared to OO code, it is much leaner, more readable, and easier to maintain. I believe OO is important and relevant, but only for large proejcts and/or large multi-person teams. For typical LabVIEW aps which are in the weeks to month range, I believe the above described design patterns are by far the most efficient to develop, and easiest to maintain. They are also very readable if done well.



Peter Blume is to be congratulated on a truly excellent book. Concise, well written, and worth a lot of money if you follow the most important priniciples.

Perhaps a good follow-on would be a more in-depth discussion of design patterns, which is where efficiency is made or broken, depending on whether the right patterns is chosen.

A final observation, is that I was not able to find the word object-oriented anywhere in this book. I surmise this may be a conscious decision, by showing how far LabVIEW actually can extend its reach with its native paradigms.

Carsten Thomsen

This book on LabVIEW Style is very helpful at getting designers of LabVIEW applications to adopt best practices so that within an organization you don't have users scratching their heads trying to get a feel for how each particular LabVIEW application author goes about designing an application before they can become comfortable using the application. This not only means better designed applications, but greater productivity within the organization.

This book is intended for readers that already have a working knowledge of basic LabVIEW principles and terminology as well as experience developing and deploying applications. The book contains the style rules for optimizing ease of use and all of the other desirable attributes of well designed LabVIEW applications. The book first shows each design rule, then provides a detailed explanation, and concludes with examples and illustrations. I found the illustrations to be particularly well done and numerous. Screen shots are shown whenever it is considered helpful at explaining the topic at hand. The following is the detailed table of contents, which is currently not shown as part of the product description.

Chapter 1. The Significance of Style
Section 1.1. Style Significance
Section 1.2. Style Versus Time Tradeoff

Chapter 2. Prepare for Good Style
Section 2.1. Specifications
Section 2.2. Design
Section 2.3. Configure the LabVIEW Environment
Section 2.4. Project Organization, File Naming, and Control
Endnotes

Chapter 3. Front Panel Style
Section 3.1. Layout
Section 3.2. Text
Section 3.3. Color
Section 3.4. GUI Navigation
Section 3.5. Examples
Endnotes

Chapter 4. Block Diagram
Section 4.1. Layout
Section 4.2. Wiring
Section 4.3. Data Flow
Section 4.4. Examples
Endnotes

Chapter 5. Icon and Connector
Section 5.1. Icon
Section 5.2. Connector Pane
Section 5.3. Examples
Endnotes

Chapter 6. Data Structures
Section 6.1. Data Structure Design Methodology
Section 6.2. Simple Data Types
Section 6.3. Data Constructs
Section 6.4. Examples
Endnotes

Chapter 7. Error Handling
Section 7.1. Error Handling Basics
Section 7.2. SubVI Error Handling
Section 7.3. Prioritizing Errors
Section 7.4. Error Handling Tips
Section 7.5. Examples
Endnotes

Chapter 8. Design Patterns
Section 8.1. Simple Design Patterns
Section 8.2. State Machines
Section 8.3. Compound Design Patterns
Section 8.4. Complex Application Frameworks
Section 8.5. Examples
Endnotes

Chapter 9. Documentation
Section 9.1. Front Panel Documentation
Section 9.2. Block Diagram
Section 9.3. Icon and VI Description
Section 9.4. Online Documentation
Section 9.5. Examples
Endnotes

Chapter 10. Code Reviews
Section 10.1. Self-Reviews
Section 10.2. Peer Reviews
Endnotes

Appendix A. Glossary
Appendix B. Style Rules Summary