Rube Goldberg Code

[gdwebb01]

Anthony, that's all very well if you know what the code is supposed to do! But working in research I have had to develop code that suites the changing direction of the project. It is frustrating, but on the plus side, while I'm alive, I'll be the only person looking at the code! I have written a network client inside my current vi. for DAQ, which has to match a commerical server, thier server protocol has undergone 12 releases since the start of the project last year (from 32-bit to 64-bit, big endian to little endian and back again, packet shape changes among other things). The project exists because the new server has become available and makes the rest of the project possible, so I couldn't wait a year or so.  

It isn't totally devoid of sub-vi's, when I'm happy the dust has settled I tidy bits up. The "vi hierarchy" shows the main program is 17 sub-vi's deep (excluding NI vi's), but it does span three screens and lacks any comments! 

I guess it would be terrible programming practice if I were to hand over the code in it's current form to a customer.

[Ben]

---

@gdwebb01 wrote:

...

I guess it would be terrible programming practice if I were to hand over the code in it's current form to a customer.

---

I have to admit that keeps me honest!

When I am done the code gets turned over so they can support it themselves. And if I "pi$#ed them off" (has not happened in the last ten years), my code get turned over to the competition so they can pick it apart to make me look bad (yes, its dog eat dog out in the LV consulting world).

But as long as I do the job right, they often invite me back for any changes that are needed. THe design and documentation make it easy for me to remeber what THAT project did and how.

Ben

[GuenterMueller]

You are not alone, Ben.  However, you are the one who has put it in the right light.

[tbob]

There are so many different people out there with so many different styles.  We should not condemn anyone's style if it works for them, (as long as we don't have to deal with it - that is another story).  I certainly would not use gdwebb01's style, but if it works for him, then let it be.  I can see everyone's point in trying to point out the "right" way, but is there really any right or wrong way?  What works for an individual is probably right.  Of course there are "better" ways, but what is better for you or me may not be better for someone else.  So lets let it be.

I've spent numerous hours changing inherited code to my liking.  That was my choice.  But I can't say that the originator was particularly wrong or that his coding style was bad.  Well it was bad for me, but not necesarrily bad for him/her.

[GuenterMueller]

I fully agree, tbob.
I am currently working on some ancient code that comes with a lot of miracles. It is my job to drive it to current demands. I wonder if the code has ever met the demands it should have fulfilled years ago. And, regrettably, the code isn't well organised.
Taking this all together, it was so easy to agree with Ben.
I did not intend to blame anyone.

[Ray.R]

---

@tbob wrote:

I can see everyone's point in trying to point out the "right" way, but is there really any right or wrong way?  What works for an individual is probably right.  Of course there are "better" ways, but what is better for you or me may not be better for someone else.  So lets let it be.

---

There is a wrong way..  That's when code is written in such a way that the only way to scale it is to re-write it. Or when code is written in such a way that it cannot be maintained.  Or when code is written in such a way that it cannot be read an understood by people who have expertise in that language. 

In this world, there is no such thing as "I am the only one who will ever look at that code".  No-one can forecast the future.  Someone will look at that code in the future.  Comments will be said about the code.  It's inevitable.  I've commented on my own code when I first started using LabVIEW.  It was bad code.  It worked, but it was still bad.  I'm glad I improved over the years.  Some people never improve, and never try to improve. When you have an opportunity to improve, you should seize it.

[gdwebb01]

I didn't expect the Spanish inquisition  

.. I chose LabVIEW because I'm not a programmer, so as long as I'm happy, that's the main thing!    

[SteveChandler]

---

@gdwebb01 wrote:

Anthony, that's all very well if you know what the code is supposed to do! But working in research I have had to develop code that suites the changing direction of the project. It is frustrating, but on the plus side, while I'm alive, I'll be the only person looking at the code! I have written a network client inside my current vi. for DAQ, which has to match a commerical server, thier server protocol has undergone 12 releases since the start of the project last year (from 32-bit to 64-bit, big endian to little endian and back again, packet shape changes among other things). The project exists because the new server has become available and makes the rest of the project possible, so I couldn't wait a year or so.  

It isn't totally devoid of sub-vi's, when I'm happy the dust has settled I tidy bits up. The "vi hierarchy" shows the main program is 17 sub-vi's deep (excluding NI vi's), but it does span three screens and lacks any comments! 

I guess it would be terrible programming practice if I were to hand over the code in it's current form to a customer.

---

Three screens is not bad at all! I have seen MUCH worse. Hundreds of subvis using the default icon and maximum number of terminals - all connected. No cllusters and terminal names such as "String 4" and "Output1". No documentation property and the subvis are set to show terminals.

The attached example illustrates what I was getting at in my previous reply to you. It is not code from a real program. I just created it to illustrate the coding style of a real program that I have had to deal with. Keep in mind that the real program spanned about ten monitor widths by seven or eight high. It wasn't all as dense as this. There were stacked sequence structures with 32 frames. The width and height of the structure was many screens in both directions. One sequence was completely packed and the rest had something like a local variable writing to another local variable leaving many pages of whitespace to get lost in. Not all controls had the default label - just the important ones. The ones that were hidden used the default label for the most part.

So your code would probably be a blessing compared to what I was talking about earlier. I know you do not code in this way.

If I were to give the subvi an icon it would look something like the following.

[LV_Pro]

No One expects the Spanish Inquisition!  - Monty Python

[grahamwebb]

Hi, this is my proper profile (and a testament to my lack of memory!)

I'd like to present this code for ridicule consideration as a Rudy Goldberg construction. It's one of those "I'm sure there's a better way, but I've started now so it will do".

A previous sub-vi searches for numbers and strings in a continuous stream of data (in a non-LabVIEW xml format), this ties them together.