Saucy Ideas

[JackDunaway]

Alright, there have been two Ideas I have been wanting to post for months, but they're a bit saucy... touchy... you be the judge. Depending on the conversation here will determine if I post these Ideas to the Exchange or not.

1. Oftentimes, I need to delve into the vi.lib to better understand how VI's work so I can know how to use them better (e.g., know what errors the VI may generate, know whether or not it modifies/normalizes input data such as a "Trim Whitespace", etc...). Since I know these VI's come from NI, I should assume that they are the "golden standard" in terms of style and readability. Unfortunately, this is certainly not the case - my cheeks have literally blushed wondering how some VI's made it out the door... and judging by the legacy indicators, it has been that way for years. The Idea is this: converge on an internal standard for style, and make all VI's in the vi.lib adhere to that standard. This would include converting all legacy controls/indicators to the most modern objects. Ideally, make the BD Cleanup SO GOOD that all it takes it to run each VI through the Cleanup... the tool is still a distance from that capability, but it is getting better. Also, develop a FP Cleanup for this purpose.

2. Do not password protect VI's in the vi.lib. This is my #1 dead-end when it comes to debugging code.

[JackDunaway]

Just read what altenbach wrote here, which is the essence of #1 above.

"The best way to improve coding habits is by example. I always try to make an effort towards diagram neatness (whatever that means) when posting an example here. Hopefully, some will rub off in the long run. " 

[smercurio_fc]

In principle I agree with #1. For practicality, I don't think this is really an issue as far as the VIs in vi.lib directory. Just because a VI looks bad doesn't mean it's bad, especially if it works properly. The example VIs, on the other hand... I think that those should really be held to a higher standard. Many of the example VIs are so ancient I suspect many at NI don't even know how they came to be. I also suspect that this would be a huge undertaking for NI to do. Perhaps it would be better to make the update of the example VIs a community project. We could establish a repository of example VI updates and have the community approve/disapprove them based on existing standards. After all, in many cases what NI thinks is a good example is not really a good example for the "real world".

As for #2, I don't really see this as an issue. NI has the right to protect its IP, and I'm not going to quibble with that. 

[altenbach]

---

smercurio_fc wrote: 

As for #2, I don't really see this as an issue. NI has the right to protect its IP, and I'm not going to quibble with that. 

---

Most vi.lib VIs are open. I think the main reason for password protection is the use of undocumented or NI internal features.

Many of the advanced processing functions are not passworded, but you get stuck one layer in at a dll call. Not much is gained here. 😉

[F._Schubert]

Maybe also because changing the vi.lib vi's is generally a bad idea. Their should be a kind of locking mechanism, which only allows you to mess around with it once you copied it to a different folder.

Felix

[JackDunaway]

---

smercurio_fc wrote: 

Just because a VI looks bad doesn't mean it's bad, especially if it works properly.  

---

 
That has some pretty strong "LabVIEW Myth" overtones. A good VI does not just generate the correct output - it's legible, documented, and maintainable. I agree, (nearly) everything in the vi.lib works, but a good portion could use some style guidance.

I have found a huge practical benefit to good style. Staring at my VI's trying to figure out how to route the wires the cleanest has led to some of the best breakthroughs in code efficiency that I otherwise would not have caught. I've found oftentimes code that looks bad is bad (don't believe me? I find no surprise that one of the largest threads on the boards is devoted to this very postulate).

Anyway, I'll drop my #2 Idea for now. I still would like to hear more thoughts on #1. 

[smercurio_fc]

---

JackDunaway wrote:

---

smercurio_fc wrote: 

Just because a VI looks bad doesn't mean it's bad, especially if it works properly.  

---

 
That has some pretty strong "LabVIEW Myth" overtones. A good VI does not just generate the correct output - it's legible, documented, and maintainable. I agree, (nearly) everything in the vi.lib works, but a good portion could use some style guidance.

I have found a huge practical benefit to good style. Staring at my VI's trying to figure out how to route the wires the cleanest has led to some of the best breakthroughs in code efficiency that I otherwise would not have caught. I've found oftentimes code that looks bad is bad (don't believe me? I find no surprise that one of the largest threads on the boards is devoted to this very postulate).

---

I was referring to the use of the classic controls over the more modern controls, not to the code. As for the code itself, you would really need to provide some guidelines on what would be considered "bad" or "good". For example, just because a wire might have a few extra bends in it (and someone may claim that it looks bad) doesn't mean it should be "revised".

[Cory_K]

---

smercurio_fc wrote:

... The example VIs, on the other hand... I think that those should really be held to a higher standard....

---

Speaking of example VI's, I would like to throw in my 2 cents about those.

Many of the brand new users look to the example VIs as a way to learn LabVIEW on the fly.

For a new user, many of those examples can be overwhelming and incredibly 'busy' looking.

I could understand that some of the examples, for example architectures or OOP, need to be more involved since they are more complicated, but there should be some really trimmed down examples as well.

For example, I like the example for 'Build Array.VI'. It is incredibly simple, and explains in detail what is going on and how.