Top LabVIEW Rookie Mistakes

[billko]

---

@RavensFan wrote:

---

@Hooovahh wrote:

Why would you choose a Strict Type def for a constant on the block diagram when it will never be seen by the user?  Why not a Type def?

---

Interestingly enough, when I took my first LabVIEW course, I think I was instructed on using a Strict TypeDef.  I don't remember whether it was the instructor or what the book actually told to use.  Sometime afterwards was when I learned that the vast majority of the time that you are better off using a Regular TypeDef and save the Strict TypeDef for those rare instances when you really need to lock down the appearance of the control.

I'm in a cleanup mode at work, so when I come across my books from the course, I'll peek at them and see what it was they were instructing to do.

---

Interesting discussion.  I am always torn between the two to the point that sometimes I'll change back and forth for a particular control.  I know, that's dumb, but...

[crossrulz]

The only good reason I've seen for a Strict Type Def is for Ring controls beings used for APIs.  Rings should be used instead of Enums if your API will be used globally.  Enums do NOT support localization since the strings are part of the data type, while Ring controls do support localization since the strings are not part of the data type.

[Hooovahh]

It actually bugs me a lot when some big cluster of data is strict for no good reason. The new LIFX is a good example where giant clusters are mode to only show one item. Then make strict so you can't just right click and arrange vertically. And don't get me started on their silver controls usage.

[billko]

---

@Hooovahh wrote:
It actually bugs me a lot when some big cluster of data is strict for no good reason. The new LIFX is a good example where giant clusters are mode to only show one item. Then make strict so you can't just right click and arrange vertically. And don't get me started on their silver controls usage.

---

That's why I keep switching back and forth.  I eventually end up usually non-strict because I come to the conclusion that the unforgiving nature of the strict is simply not worth the hassle.

[RyanWright]

Besides the 5 rookie mistakes mentioned in your article, some of the other most common rookie mistakes I see are:

1. Not establishing and documenting project requirements before writing code or designing architectures and interfaces
2. Not designing appropriate architectures and interfaces before writing code (this is much more than just selecting a design pattern)

From my experience, these two mistakes are almost always to blame when code is not scalable, modular, or maintainable.

[mikeporter]

One big one is failure to think ahead. People go into a project assuming it (or the requirements) will never change.

Mike...

[Hooovahh]

---

@mikeporter wrote:
One big one is failure to think ahead. People go into a project assuming it (or the requirements) will never change.

---

Agreed.  The issue is broader than a rookie LabVIEW mistake and really a tip for any one at the program manager level or below.  I used to have a sign in my cube that was just a white sheet of paper that said "Remember to get everything you need" which on the surface isn't all that funny, but it was a quote from a manager at the start of a program, that had no product, no method to communication to the product, no tester,  and no specifications.  I didn't know enough to know what I needed yet.