Programming Paradigms: or why we do what we do the way we do what we do.

[Hornless.Rhino]

Did a search for this, but couldn't find anything.

So I've been thinking lately about different programming styles. Looking through the VIs that many people post to various things (see the rube thread for some of the more unique examples), and comparing them to the sheer ingenuity of some others, which may not necessarily be simple, but still great.

Then there are VIs that look like the wiring at the back of my computer/printer/router/etc (note: not neat), and others coded with precision such that there is a beauty radiating from their VI.

Then there is the use of superfluous structures to impose some kind of sanity to a VI that doesn't need it (such as using sequences for self sequencing code (i,e. sequence already set by wiring from one standard block to another)), whereas others may just leave some space filled only with wires to split up sections of code (subvis aren't always appropriate).

other reading:

Rube thread

Local variable thread

http://forums.ni.com/t5/LabVIEW/LV-Style-Guide/m-p/160729

http://forums.ni.com/t5/LabVIEW/memory-management-and-style/m-p/132236

I guess where I'm leading to with all this,

Are the any circumstances where you would (of your own volition rather than due to a request) go against what seems to be good style? If so what would you do instead and why?

A few examples:

1) The same chunk of code is used to perform actions on X number of grouped inputs from an array for example. (X>1)

-Could you think of a case where you could do the whole "copy and paste" thing rather than using the for loop?

1a) A situation where a for loop is not really needed. Such as a small amount of code in the "loop", perhaps X<3

-Could you think of a case where you'd use a for loop anyway?

-What if you ignore the possibility of future expandability.

2) A series of say 10 chunks of code within a VI. Subvis won't work in reducing the clutter, and would have the potential of making things more messy. Each of these blocks has inputs directly from the outputs of the previous chunk, plus a changing input which comes from the output of say a different array index for each chunk. This array is determined at the start.

Would you ever consider putting this code into a sequence structure (stacked or otherwise), even though it doesn't need it?

3) Similar thing but with a while loop.

4) Similar but with clusters, arrays, signal merging etc.

5) Any other situations you can think of?

Not so much IF, you break style, but WHY you do or would break style (of your own volition).

[Intaris]

Wild ideas as possible solutions to problems lead to all kinds of style violations, especially when they work as their survival rate is then much higher.....

Time is a crucial factor in simply getting the fastest solution (Time to implementation) out the door......

CUI.....

[tst]

First, I think you should always be ready to break style. Never let rules get in the way of your coding. The rules don't fit all situations and sometimes you need to know that they can be bent (I'm sorry, I'm getting a bit Matrixy here) and what the implications of that bending are.

Anyway, here are specific examples:

Using parallel duplicate code instead of a for loop -

1. Because you want it to execute in parallel (ignore the new parallel loop feature, since it's new).
2. Because a reentrant subVI in the code has a USR and you want each copy to keep its own value, which means you need different instances of the subVI in memory.
3. The same as 2, but with a notifier (The last couple of versions of LV have notifier primitives to deal with this, but they have their own issues).
4. Because a lot of the code is duplicate, but a lot of isn't and separating the two parts using case structures is difficult.
5. Because they produce arrays of different values and you don't want them to be padded. Another way of handling this is wrapping the array in a cluster, but that's not always a good option.

As for your 1a, usually a loop should be the default option, even if it's only a couple of iterations. Conditions such as the ones I presented would usually have to exist for me not to use one.

As for your number 2, I would definitely consider putting code in a SSS. The main use case that comes to mind is a case where you have a lot of code which has no sequential dependencies, but has to be performed sequentially and all of it has to be run every time (so a state machine becomes less relevant).

There are many ways in which you can write such code, but the SSS is the easiest both to build and to debug.

The two main disadvantages it has is that it can create large VIs and that you can't easily transfer information from one frame to the next. You have to either use sequence locals (which I really dislike) or other methods. Shift registers would have been good for this, but they have been rejected.

[aeastet]

The only time that I think I do is when I am trying to solve a problem. I let the ideas flow onto the screen and when I have the solution I go back and try to find the best way to code it.

Most of the time I am trying to do this right from the start but sometimes you head down one road to find that you should have gone the other way. Things like this sometimes need a bridge. Bridges a costly and time consuming but get you where you need to go until you get a more elegant solution in place.

[Ben]

"WIre bends behind objects"

I'd rather take the hit from the VI Analyzer than see an unsightly bend.

Now that I have been working a lot in LVOOP, I have gotten lazy about "Labeling Shift Registers" since the lable would be rather meaningless "LVOOP data of an unknown class".

Also influenced by LVOOP, I label few wires since the "Accessor Method" is right there telling what the data is.

Ben

[tbob]

I occasionally use a left to right wire in order to fit my bock diagram on one screen.

some code ------- more code

                              |

                              |  

                              |______

                                         |

some long long long code----

[Ray.R]

no time to read the entire thread at this time, but, on this forum I usually fall into the category Shane talked about:

---

@Intaris wrote:

Wild ideas as possible solutions to problems lead to all kinds of style violations, especially when they work as their survival rate is then much higher.....

Time is a crucial factor in simply getting the fastest solution (Time to implementation) out the door......

CUI.....

---