Is there a way to make the wires disappear?

[_S_G]

I agree with all the posters above who say that  you should not be trying to get rid of wires.  You wouldn't try to get rid of text in a c program, would you?

What you  should do is organize your wiring using the suggestions above (such as creating subVI s, clustering your  wires, etc.).

[Hosehead]

I disagree about using Sub-VIs to clean it up, or that having a code too big to fit on one screen is somehow wrong.  I like to see everything at the top level and so have all my code layed (laid?) out that way.  That way I don't have to go clicking all the sub-vi's and having a bunch of programs all open at once - it just makes me more confused.  And I don't have to deal with all the extra programming or work arounds that results from using sub-VIs.  The less extra coding, the less likely a mistake.  Plus for large programs, it's easy to get around using the Navigation Window (why else is it there?).

As far as keeping it neat, I just pay a lot of attention to layout so that I don't get a spaghetti mess.  The result is very much like a wiring diagram for a complex system (such as your car).  And don't forget the most important thing is comments.  When you're working on a large program, it will not only be easier for someone else to see what's going on, but for you as well, when you come back a month later and wonder, why did I put that in there?

I think it's just a personal preference.  But I'm not a veteran or professional though, and my brain can't handle too much, so no need to pay any attention!  (And feel free to critique, I stand behind my method, since it works for me and everyone else I work with!)

See the screen shot below of my largest program's block diagram.  Notice the white box in the upper left corner is the size of my screen, making the total block diagram about 10 screens wide and 6 screens tall. 

[GuenterMueller]

Impressive. But it is not the type of VI I'm looking for to do some refactoring.

Guenter

[tst]

---

@Hosehead wrote:

The less extra coding, the less likely a mistake...

When you're working on a large program, it will not only be easier for someone else to see what's going on, but for you as well, when you come back a month later and wonder, why did I put that in there?...

I'm not a veteran or professional though, and my brain can't handle too much

---

It's interesting you should bring up those points, because they are often used to prove the exact opposite - when you make a reusable subVI, you don't need to test and code it again and again. When you have functionality encapsulated in a small icon, it's much easier to understand than having a large block of code (and a subVI can and should hold documentation which you can see with the context help window). When the functionality is in a single icon, your brain does not have to handle all the unnecessary code.

Just look at the NI VIs you use and imagine what would happen if the code for those VIs was inside your main VI.

Also, try imagining a more complicated project. Let's say you had to write a relatively simple program like Notepad, Paint or Hyperterminal. Think how large a single diagram would be.

[mikeporter]

Yes, very impressive - in a mindless sort of way... Interesting how appropriate forum handles can sometimes be.

Actually I guess I shouldn't be too hard on ol' hoser. After all I have made a lot of money over the years fixing stuff like that.

Mike...

[smercurio_fc]

Hosehead wrote:

---

(a bunch of stuff and posted a picture that made my eyes hurt)

---

Are you serious?!? This is how you code?!? No offense, but did you not take even a single class in computer science? I have an EE degree, so I'm not a computer science expert, but I had to take computer science as part of my curriculum. Your example is the classic example of how not to code. Your method completely disregards decades of computer science development and the whole idea behind class oriented design. The fundamental problem with your method is one of inability to scale, as tst alluded to. Other problems:

• Lack of control. You're constantly scrolling huge amounts just to get wires around. This makes programming far more tedious.
• Lack of encapsulation. If you want to change how one small part of the code works you affect *everything* else.
  
• Lack of reuse. If you have an operation that needs to be done in several places your method requires copy and past of coding, which actually increases the possibility of errors.
  
• Lack of robustness. Let's say you have a file problem and your VI gets corrupted. Your entire project is screwed. With subVIs you minimize this risk.
  
• Lack of delegation. With your method having more than one person working on different parts of the code is impossible since it's all in one place.
• Lack of testability. How can you go about testing your code without resorting to have to test the whole thing? This is impractical and also disregards decades of development in testing, so you're batting a perfect score in ignoring established design principles.
  

You also said "The less extra coding, the less likely a mistake", claiming this was justification for your method. This is not a justification for your method of programming, but an excuse. The paradigm is intended, among other things, to prevent Rube Goldberg coding.  I would counter that anyone programming in this method suffers from a lack of programming skills and thinks more like a circuit designer than a programmer.

I would strongly recommend that you pick up some books on proper programming practices. Should you find yourself out of a job and need to get a new one you may find yourself looking at a lot of astounded faces from people who look at your code. Certainly if you were to ask for a job where I work you'd never get one.

Message Edited by smercurio_fc on 07-24-2007 03:40 PM

[Ben]

Hi Hosehead,

Speaking as person who once wrote code like that, I have to urge you to reconcider your style.

I have customers that have paid me to re-write code like that.

Well written sub-VI's will help make your code easier to read and not harder.

A new reader of your code would have to triple-click on wires and chase them 12 screens down to see what happens to it.

If those are decorations on your diagram to seperate code portions, then those are probably candidates for sub-VI's.

Trying to help,

Ben

[_S_G]

Well, I don't like to force my programming style onto somebody else, but let me just explain the reasons I have for not using your style.

When I first started using LabVIEW, I had a similar opinion as yours, Hosehead, and I tried to resist using subVIs.  I still write code like yours for extremely small VIs or VIs where I'm just creating a prototype, or a quickie application that I will be running myself only once or twice.  But I think it is inappropriate  to have that kind of code for any large application because:

1.  It is difficult for someone who is unfamiliar with the code to take one look at the diagram and get a big picture view of the code.  One tends to get distracted by the details. 

2.  Blocks of code that have similar functions cannot be reused.

3.  Difficulty in making modifications (moving blocks of code around, etc.)

Regards,

Message Edited by S G on 07-24-2007 03:44 PM

[mikeporter]

Your comment about "circuit designer" is interesting because one of the things that struck me about his image is the resemblance it bore to a blow-up of an integrated circuit chip.

Mike...

[smercurio_fc]

Indeed. That's precisely why I made that comment. In my experience, and coming from an initial EE background, I've seen circuit design engineers try to program in the same way they design circuits, and the result is code like that shown in the figure.

I also found it quite interesting that all comments so far have not been in support of that programming style, yet at the time that I write this response, I seem to be the only one to have warranted a single-star rating. Hmmm.... I wonder... I would also challenge the person who gave me the single star to justify it. (Aside: I hope we get this star system fixed soon.)