Shift registers for Stacked Sequence Structure

[David_Ferster]

The one place I use Stacked Sequences is for setting up various parameters at the start of a vi. I usually have several frames, especially if the setup is complex, with each frame performing a different class of operations (reading from config files, checking for hardware, setting control appearances, etc.). And often, I find that multiple frames need to plug values into clusters at different points in the setup sequence. Sequence Locals for passing these clusters from frame to frame are terrible since wires have to backwards to come out of the locals, and the result is ugly and non-intuitive. So why not not have Shift registers, just like in loops. Much nicer. It might make Stacked Sequences more acceptable.

[Ray.R]

Yes... that's the one..

If I can recall properly, I think NI wanted to offer some sort of structure that would comfort some text based programmers.  They came up with Local Variables (which mostly get abuse and lead to code that are full of race conditions) and Stacked Sequence Structures..  I used them in my early foolish days of doing LabVIEW development..  The shame!!!!  I'll never put it down.  What horrible code I wrote...  😞

Stacked Sequence Structures, like their distant cousin Local Variable break the data flow which is the most important factor in writing proper graphical code.  People tend to force sequential flow using SSS.  But LabVIEW uses data flow when executing code.  The mindset is completely different.

[tst]

---

@Ray.R wrote:

I agree with tst's first post.

---

Then you must not have read it very well. I said "people" say that, not me. I personally think that SSS could be useful and that SRs would improve them.

[Ray.R]

You're right.  I had not noticed your closing sentence..  

Thanks for the correctionn... 😉

I should edit my initial post to:

I agree with all the other people tst referred to in his initial post.  😄

I should elaborate.

In my travels, I have seen horrible code.  When I say horrible..  I really mean horrible.  SSS with 50 to 80 frames, in which may contained SSS which had 40 to 50 frames.  Some of the nested frames had a 3rd layer which contained 20 frames.  Nesting SSS is so horribly bad.  Imagine signing a contract to which one of the sub-vis that you had not investigated contains one of those monters!!  The B@*D that wrote that code fled the nest because he could not add an additional feature.  I then had to explain to the client that it would be better to re-write the code from scratch!  Can you imagine how many total frames that was??!!  %$@$^%#@%$$!!!!

People NEED to learn to code properly!  Giving more rope features so that they hang either themselves create headaches for themselves or to the poor soul who has to fix the horror is NOT a good idea!

I cannot support ideas that contribute to poor coding practice.

[Alex.T]

I don't know. With the example you've given with 50 to 80 frames, I'd say that's probably down to bad programming practice in general, maybe due to someone misunderstanding the LabVIEW fundamentals.

I don't agree with saying that Stacked Sequence Structures don't abide by dataflow. I think have the potential to be a useful way of encapsulating a routine that would otherwise take up a lot of space on the Block Diagram and help things look a lot cleaner. Then again, I think a lot of us are thinking about the Case Structure. Y'all look alike. What makes those so readable though is the fact that each case has a unique condition, which allows for way better random access when programming. For a SSS, it's just numbers and strict inflexible ordering. I guess what divides people in this thread is code cleanliness vs. readibility, which oddly enough seem to be mutually exclusive when it comes down to this type of Structure. Pretty sure that has to be a programming first...

The only reason that I don't use SSSs is because of the sequence locals. They're the only element I can think of that allow SSSs to inevitably create bad looking code, otherwise I think I'd use them a lot.  The suggestion offered is seems like a great workaround for this problem, but imagining the flat equivalent with a lengthy tunnel going right through every frame being unused is a little off-putting. As soon as one of those wires stops being used for a good number of cases, it's probably time to move to a new area of code.

... You know, the more I think about it, the more I agree with you guys. They should probably be avoided like the plague. We should suck it up and use SubVIs as reccommended, or a state machine.

[David_Ferster]

I will attest that one can write really bad code very easily without the SSS. And at the same time, one can write pretty decent code with judicious use of SSSs for creating a one-time sequence of events.

[David_Ferster]

I wonder if some of the disagreement is partly because of our situations. Some of you guys are working in teams and have to write code that meets specs and can be maintained by other people. I am more of a cowboy coder (though with a few thousand users), and so I am willing to take a few shortcuts in the interests of time, and when I am the only one who suffers if I do it badly. It's a lot quicker to make a sequence of frames than to create the same number of one-time vi's, arrange their connectors, make their icons, and so on. If I were writing for posterity, I'd certainly do the latter, but when I want to get some code to my users quickly, I like the flexibility of the former and would hate for NI to censor me by eliminating SSSs.

On the other hand, I have benefitted greatly from these discussions, cleaning up my act where I can and learning how to do things properly.

[Intaris]

Being able to hide your code from prying eyes doesn't make it good code.

Having said that, I udnerstand your differentiation.  But a lot of people transition from being cowboy coders to teammates and that's where the problems start.....

[Ray.R]

I wish I could give Alex and Intaris kudos.  They hit it right on the target.

David, I think what you'd like is another structure that was proposed... And I think you're trying to propose it..  I'd have to dig for it and I can't remember what I said for that idea...which I think was turned down..  It was probably a couple of years ago...

I like your analogy to a "cowboy coder"..  Unfortunately, consultants like myself often get called to fix / scale / do something with cowboy code.  We look at it.. want to puke...  and then -sigh- try to convince the owner of the code that it is best to start from scratch.

You may be coding by yourself, on your own, and think you're the only one that's ever going to see that code.  Well... chances are that you are wrong.  It depends on the legacy you want to leave behind...  You may be asked to implement something that is poorly handled with the SSS (or a modified version of the SSS), and it will be nearly impossible.  I had to deal with the code of some guy that kept running away from his own code to the point that when I met with potential clients, I would ask if the person who worked there previously was named such and such...

It's a small world.. Much smaller than you think.  I see code from coast to coast.  I know who's good and who's bad.  I'm sure I'm not the only one with that experience.

For whatever it's worth, good coding practice goes a long way. 

[David_Ferster]

Exactly. I have imaginary conversations all the time with the poor b@*d that will inherit my code. That's why I try all the time to improve and de-obfuscate (as well as for me 10 years from now).

How does a SSS "hide" code any more than a mess o' vi's?

[Ray.R]

LOL!!

I know the guy who inherited one of my first code.  I'm sure he would never believe that I progressed to the level I'm at now... And I'm still learning..  😉

Maybe "hide" is not the exact word..
It's not easy to find..  Those darn number do not describe what's going on inside that frame..  Plus, there's nesting..  Something that just should not be done using a state machine!

The advantage of the state machine is that you can give meaningful names to whatever goes on inside that state.  Plus, since it is not sequential, you can programmatically decide which state runs next.  Can't do that with SSS.  If you do try to do it, you won't get far and it'll be very messy..  😛