Named Frames in Stacked Sequence Structure

[InfiniteNothing]

To improve the built in documentation of the code, and to make selecting the right frame easier, I suggest that we should be able to name frames in a stacked sequence:

Preemptive defense of stacked sequence structures: A stacked sequence structure takes up less room on the block diagram than a while loop and a case structure. They serve a very specific function that tells code readers that there's not going to be any funny buisness in jumping around from frame to frame. You can't accidentally write an inifinte loop, skip frames, etc. Don't let the abusers obstruct the legitimate use of these structures.

[Ray.R]

shame I can't give Mark Kudos for his reply..  😞

Kudos Mark!

Like you said Darin... Lipstick on a pig..  No matter how you slice it... it's still bacon. 

[Darin.K]

The extent to which I am simply playing Devil's advocate I won't say, but let's say I put the offending code in a subVI. Most times it is already a subVI, so now I just push the same ugliness one level down, no difference at all, except hidden code and extra steps. This method has not proven satisfactory for .NET or scripting-heavy applications. I do not like unitasker subVIs, with little reuse potential, whose purpose is to hide sprawling code. A method to stack the code vertically saves screen space and clicks. What is funny is that I could write a typedefed state machine which ran the states sequentially and everybody would just say how nice it is. I do not get paid by the hour so I look for cleaner quicker solutions. This may or may not be it.

[Ray.R]

One day, with LabVIEW-3D, it will give new meaning to the Stacked Sequence Structure...  😉

I don't want to spend too much time going over all the bad things with SSS, but SSS breaks some basic rules from the Coding Guidelines, such as if you do want to preserve data flow, you need a whole bunch of sequence locals and then the wires flow from right to left, left to right, etc.  I am not even mentioning all the abusive code that breaks many other proper coding practices...

Now, if the SSS was redesigned to fix all that, then we would no longer be talking about SSS...  Maybe this other entity (structure) would be better..

[ErnieH]

Collapsible code for glue logic.

[tst]

>...such as if you do want to preserve data flow, you need a whole bunch of sequence locals and then the wires flow from right to left, left to right, etc.

Ray, it's interesting you should mention that, as that is exactly the issue which was supposed to be addressed with the shift register idea I linked to earlier. Whether you call the structure which has this SSS or something else is irrelevant.

As for the other disadvantages people usually attribute to SSS:

1. It hides code. Blah. So do case structures, event structures and VIs, and people don't have a problem with those.
2. It creates artificial timing dependencies. Duh, that's the point. Don't use them if that's not what you want.
3. It discourages modularity. Can't argue with that one, but not all programs need modularity.
4. It's not flexible. If you want your code to make dynamic decisions, you can't. A fair point. Don't use it in that case. Use it when you don't want to dynamically control the order.

Of course, people usually make the claim that even if you can use the SSS properly, the vast majority of people using it are actually abusing it, because it's there and it's the obvious choice. I can't argue with that. That claim is probably correct, but it has nothing to do with the technical merits of the SSS.

[Ray.R]

You know what Yair...

You speak the truth...  As with our chants of "Anti Locals" or "Anti-This" and "Anti-That"...  it is not the particular feature that is the problem, but rather the inherent abuse that seems to naturally evolve from it.  What if LabVIEW actually addressed that?

In your list you forgot an additional element.  If the code was to be cycling in nature: ie Step A with arg 1, Step B, Step C, Step A with arg2, Step D, Step A with arg 3, Step B with arg 4... and so on...  The SSS would not take advantage of repeating the same State (an in a SM) with different values for the same arguements.  SSS do not scale nicely either.  I have yet to see code that does not scale up in the future.

In the above example, my intent is not to bash SSS.  It is not a structure that I would use or recommend.  I am not sure how changing it would improve things.  And I do not know what a "new entity" would look like to suggest anything.  I should look at the thread that you mentionned to see what is discussed..

[MichaelWestwood]

Hi,

There is a side of this discussion which has not been addresses as far as I can see.

People like me who have been using labview since version 6 or earlier will remember that the stacked SSS was a fundamental structure in Labview in those days (even the Labview logo and icon included it!). 

While I'm sure we all agree the concept of the SSS is flawed, some of us still maintain code which originated in those days for systems which still run in critical industrial applications and to rewrite that code is simply not feasible.

The idea of named frames in the SSS would allow improvement of the readability of that code without compromising it's funcitonality. In that software our practice was that each frame contained a single function and currently I manually maintain a comment in the diagram which has a list of which frame does what but this is painful and unreliable since, for example, there is no evidence of whether another engineer may have changed the code without updating the list.

In conclusion, I think remove the SSS from the pallet by all means and discourage it's use, but the addition of this function would be very useful from the point of view of long term support, and that's something engineers in my field of work are extremely conscious of. 

Cheers,

Mike 

[Darren]

National Instruments will not be implementing this idea. There is no further feature development planned for Stacked Sequence Structures. Additionally, you can use subdiagram labels in a Stacked Sequence Structure to label the individual frames.