Community Nugget 2-19-2007 "Stacked Sequence Exterminator"

[altenbach]

I am sure everyone with even casual familiarity of LabVIEW has run across older (or newer) code that is just peppered with ...

Stacked Sequences from Hell.

Stacked sequences (especially the one's containing sequence locals) are the hallmarks of confusing, unreadable and unmaintainable code. Data flows in all directions (mostly right-to-left), a large percentage of code is hidden at any given time, and it is almost impossible to debug and follow what going on. Often there is clear data dependency (or execution order does not matter), so the sequence serves no purpose. Better programmers don't use stacked sequences at all and even keep flat sequences at a minimum.

---

Here is an example:

Since the code seems to work "sort of", and trying to rewire things manually will probably lead to accidental errors, we have no choice than to leave things in place...

... or do we??? 😮

---

If we try to right-click on the sequence, we can only remove individual frames, breaking everything in the process. No go! A dead end!  Sigh! 😞

---

But let's not give up just now.... We can easily convert the stacked sequence to a flat sequence, so lets do that as a first step:

---

At this point, we can remove the flat sequence and all connections remain in place. Now we can just cleanup the elements and wires and everything look much better. Ahhh!!! 🙂

In summary:

An easy two-step procedure allows us to exterminate unnecessary stacked sequences without any danger of breaking the code. This method should lower the fear to remove these monstrosities. 🙂 Try it today!

---

This is a Community Nugget. If you want to contribute, please sign up here: http://forums.ni.com/ni/board/message?board.id=BreakPoint&message.id=3379#M3379

Message Edited by altenbach on 02-18-2007 10:43 PM

[shoneill]

Wow,

I'm blown away by the pure multimedial impact of Altenbach's nugget!  Now that's raising the bar for all who follow......

Ob by the way, nice tip.  Since I only recently upgraded bayone the 6.1 barrier, this is something I wouldn't have known otherwise.  Training? Get it online 😉 !

Shane.

[HJPhilippi]

Hm, somehow I agree with what you're saying and somehow I don't...

Yes, stacked sequences may hide a lot of code at a time - but maybe that's what you actually want?
I think many people (like me) use it for exactly this reason: As you've shown, there's never a necessity to structure or force a certain data flow with it, but it may help you (and your fellow coders) visualize the way you approached your programming task in a step-by-step manner: After doing A, we go on with B and finally conclude with C - doing so in 3 sequence frames. Like I insert some extra empty lines and // comments to visualize "blocks of action" in a single C# function I write. No need to do so for the code semantics, but helping me outline what I'm doing one thing after another.

Sure, I know that at this point one should consider true encapsulation of what you're doing blockwise and create sub-functions/VIs - and this is what I'd do after the rapid proof worked and/or the sequence frames grow too big or unhandy. Again, a sequence may help you identify and group together what could be encapsulated before you do so!
And by the way: Sub-functions/VIs hide a lot of code, too. In fact, mostly you're glad they do so!

My conclusion is: One should keep in mind that stacked sequences are not and under no circumstances a necessary element of G coding, that's absolutely right. But used sparingly and with reason, they can be a nice helper to point out things in G "grammatics".
🙂

Greetings,
Hans

Message Edited by HJPhilippi on 02-19-2007 11:06 AM

[Tomi_Maila]

Nice nugget altenbach!

I think framed sequences with all those sequence locals are quite a mesh. I have visioned of following improvement to sequence locals. Allow adding shift registers to stacked sequences. Shift registers would solve a common problem of passing an item from one frame to another in a much nicer way than using sequence locals. Unlike shift registers in loops, shift registers in sequences would not require each frame to wire a value to right hand side shift register tunnel. In such a case the previous value would be used in the next frame. I herby ask NI to make our lives easier with these new kind of shift registers!



Tomi

Message Edited by Tomi M on 02-19-2007 12:17 PM

[Tomi_Maila]

I add one more image to express unwired shift register.



Tomi

Message Edited by Tomi M on 02-19-2007 12:35 PM

[tst]

Great suggestion, Tomi. Did you file a product suggestion?

Nicely done, Chris.

[Tomi_Maila]

Tst, thanks for reminding about product suggestion. I just submitted it. I hope we see this feature already in LV 9.

Tomi

[Ben]

Thank you for taking the plunge into Nugget-Land Christian!

Nice start.

For the most part I am with you on not using stacked sequence structures. I teach all of my new hires to not even concider them.

But some years ago I had the oppertunity to work with "The Architect Supreme"* and she pointed out a wonderful use of the stacked seq.

DOCUMENTATION!

It is really handy having the design diagrams just a click or two away.

Ben

*"The Architect Supreme" was the first person to earn cetification as both a LabVIEW and TestStand Architects. In this case it was "May the best WOMAN" win!".

Message Edited by Ben on 02-19-2007 07:45 AM

[Tomi_Maila]

Ben, very good point! There is another excellent use for stacked sequences, error handling! Make your program code as frame zero and add one frame for each error that may occur in your code and that you want to catch before exiting the diagram. This makes your code very readeable and hides the not very interesting error cases from the user. Error handling often takes quite a lot of space from the diagram.



I used the non-existent shift registers to express how they may be handy in error handling especially.

Tomi

Message Edited by Tomi M on 02-19-2007 04:02 PM

Message Edited by Tomi M on 02-19-2007 04:03 PM

[Ben]

Tomi,

Aren't you asking for a good reason to use a "bad" construct?

Your suggested code construct would look like this.

After wondering how to make it faster, you would concider this.

But the revised version is not possible with a stacked seq. With a State Diagram you have a lot more flexibility, and you have it now.

Now don't get me started because the next thing you know I will be talking about the SDE* and this thread is about exterminating Stacked Sequences..

Wait, I think I just did.

Ben

* With a State Diagram you have a lot more flexibility, and you have it now. If you use the SDE the graphic documentaiton comes along for the ride.

Message Edited by Ben on 02-19-2007 07:59 PM