Common behaviors among LabVIEW Developers

[joaopam]

Hello friends,

Well, I'm sorry if I should start this thread in another section, but I think this is a pertinent discussion about LabVIEW development practices.

Today I'm celebrating my first year working with LabVIEW. Before that, I had never heard about it (I think that's because I'm an IT Technician and I'm only 18).

Anyway, the point is: Am I the only one that freaks out because of the block diagram neatness?

I've just finished one medium project (5 VI's, VISA based) and I noticed that I've spent much more time working in details than in the whole architecture or code. I simply don't stand unecessary bended wires, lots of free spaces and everything that makes the code look a real mess.

Is this actually good or I'm wasting my time?

I'd like to post my VI here, but I'm not allowed to this. The fact is, my first medium project started from zero has a modularity index of about 4.5% and no warnings about Node Density (25%) or Diagram Size (1280x800, my current resolution). I know they aren't impressive numbers, but I'm satisfied with them.

I would like to know your opinion about how worthy is the neatness of the code and what aspects should I give more attention when "cleaning up" the whole diagram in my next project.

Thank you all

Regards

[crossrulz]

My block diagrams tend to very clean.  My cleanup is typically done when I'm going back through my code as a personal code review.  I have heard from the LabVIEW R&D guys that they just use the Diagram Cleanup tool (CRTL+U or the broom button in the block diagram tool bar).  I know there's plenty of guys here that absolutely hate the Diagram Cleanup tool.  I rarely like its results.

To help myself, I actualy made a quick drop plugin to do various clean up processes for me.  That has save me a ton of time.

Yes, clean diagrams are important.  But the important thing is the readability, not necessarily how clean the diagram actually is.  If you can't read the code, it is next to worthless.    And you would be surprised how much simple documentation can help in that.

[joaopam]

I tried to use Diagram Cleanup Tool, but I'm part of the ones that don't like it's results. 

What do you mean exactly with redability? Following the Dataflow "rules" is one of the itens that make it improve?

Thanks for your feedback.

Regards

[billko]

---

@crossrulz wrote:

My block diagrams tend to very clean.  My cleanup is typically done when I'm going back through my code as a personal code review.  I have heard from the LabVIEW R&D guys that they just use the Diagram Cleanup tool (CRTL+U or the broom button in the block diagram tool bar).  I know there's plenty of guys here that absolutely hate the Diagram Cleanup tool.  I rarely like its results.

To help myself, I actualy made a quick drop plugin to do various clean up processes for me.  That has save me a ton of time.

Yes, clean diagrams are important.  But the important thing is the readability, not necessarily how clean the diagram actually is.  If you can't read the code, it is next to worthless.    And you would be surprised how much simple documentation can help in that.

---

That being said, a clean BD goes a long way towards readability.  There actually can be too much of a good thing, though.  I see some people who will make wires go behind sub-VIs just because they can't stand bent wires.  Then it looks like the wires go into/out of the subVI, which makes troubleshooting orders of magnitude more difficult.  Other times they hide code in stacked sequences to save space, when really they should be thinking about sub-VIs.  Sometimes they will use local variables with impunity because it "cleans up those messy wires."  (I paraphrase that from an actual post here.)

I think a neat BD in itself means that you pay attention to detail, and that's a good habit to have if you're a developer.

[RavensFan]

Readability:

1.  Don't have hidden wires or functions.

2.  Don't have wires that run backwards.

3.  Minimize unnecessary bends in wires.

4.  Don't have the diagram be too tight that wires are too close together you can't follow them.

5.  Don't have too much empty space on the diagram that the functions get so far apart, you can't find them.

[joaopam]

---

billko escreveu:

Sometimes they will use local variables with impunity because it "cleans up those messy wires."  (I paraphrase that from an actual post here.)

I think a neat BD in itself means that you pay attention to detail, and that's a good habit to have if you're a developer.

---

In my early LabVIEW days, I was addicted to local variables. Sometime ago I saw the problems of using it improperly. 

Assuming that I'm a person that care too much about the details (not just in development, but life in general), I'll take your last phrase as a way to be satisfied with myself.
Thanks for your feedback, Bill.

[joaopam]

---

RavensFan escreveu:

Readability:

1.  Don't have hidden wires or functions.

2.  Don't have wires that run backwards.

3.  Minimize unnecessary bends in wires.

4.  Don't have the diagram be too tight that wires are too close together you can't follow them.

5.  Don't have too much empty space on the diagram that the functions get so far apart, you can't find them.

---

I like those rules.

Looking at my code and comparing with what you've said, I think I'm in the right way. Maybe I have to improve my skills in number 3.

I've written them in my office's white board, so I can remember the "Readability Rules" when I'm doing something stupid.

Thanks for your feedback.

[SunshineDesign]

The book "The Labview Style Book" by Peter A Blume is the best place to get Labview code standards from. It is well written, has sensible code standards and is one of the best Labview reference books out there. (There are not many good Labview books). The only other Labview book I recommend is "Labview for Everyone". 

[RavensFan]

---

@joaopam wrote:

---

RavensFan escreveu:

Readability:

3.  Minimize unnecessary bends in wires.

---

I like those rules.

Looking at my code and comparing with what you've said, I think I'm in the right way. Maybe I have to improve my skills in number 3.

I've written them in my office's white board, so I can remember the "Readability Rules" when I'm doing something stupid.

Thanks for your feedback.

---

Just to clarify.  I don't think you need to put an excessive amount of work struggling to make all wires straight.  (Although I myself try to knudge different nodes and tunnels around if a wire seems to have a slight kink in it.)

I think having a few bends is okay.  When you see diagrams that have dozens of bends unnecessarily because the person just clicked away all over the diagram in drawing a line from point A to point B, that is when there is a problem

[joaopam]

---

SunshineDesign escreveu:

The book "The Labview Style Book" by Peter A Blume is the best place to get Labview code standards from. It is well written, has sensible code standards and is one of the best Labview reference books out there. (There are not many good Labview books). The only other Labview book I recommend is "Labview for Everyone". 

---

Thank you for the tip. I'll be looking forward to read this book. It seems to be interesting.

Regards 😄