As a Product Owner for LabVIEW, I would not approve using block diagram cleanup for this type of refactoring operation, so I'm declining this idea.
we correctly recommended that the SSS be removed from the Structures Palette. Let's go one step further. Default Block Diagram Cleanup to apply the existing "Replace SSS with FSS."
There are legit reasons for wanting a stacked sequence structure -- that's why a flat sequence structure can still be converted into a stacked sequence in the right-click menu. Since you cannot drop the stacked sequence from the palettes any longer, anyone who adds one has done so deliberately and explicitly, and cleaning up the diagram undoing an explicit setting like that would be unlikely to be appreciated.
There are very few legitimate reasons for the SSS. (You may recall, I was one of its last hold-outs arguing for keeping it) anyone bright enough to use that correctly is certainly aware that the structure can be excluded from Block Diagram Cleanup with a single right click.
And, based on conversations at 2019 NIWeek, no, I would not assume even half of LV users know that individual structs can be excluded from cleanup. It's weird what hits with customers and instantly becomes part of The Cultural Knowledge and what just lingers on the edges.
we correctly recommended that the SSS be removed from the Structures Palette. Let's go one step further. Default Block Diagram Cleanup to apply the existing "Replace SSS with FSS."
Anti-kudos... One day the BD cleanup tool may be able to learn my coding style sufficiently well to allow me to focus exclusively on function, but that day feels a long way off. For now I believe good LV code is about both form and function, and the cleanup tool just can't match the form of a good human. At best it is a quick way to tidy up a small amount of code that was thrown together in a hurry. On larger code chunks it just tends to de-optimise the layout.
IMO the idea of the cleanup tool swapping out structures based on some "universal style definition" just feels wrong!
Stop messing with people's programming style. NI is not the teacher grading people's programming according to some obscure general style definition, it's the servant that provides the tools for people to do their work.Servants are not supposed to patronize the people they serve!
@Merlin_Walker : does N serve just the code author or also the code reader? 🙂 In this case, I agree with you: rewriting the stacked structures would be a bridge too far. But in a general argument, NI's role is not "teacher" but rather "arbiter among users" to try to maximize the comprehension and reusability and maintainability of G code. There are some styles that fly in the face of that. Every programming language in use today has a standard style guide with explanations for why things are done a certain way, and many compilers have taken steps to enforce those guides. LabVIEW is one of the more hands-off environments, and I personally think that's good, but there are moments when the IDE should step in and push back on style. NXG had* an excellent, in my opinion, balance on that, and there are some aspects from there that would interfere with some users' style that I would support porting into LabVIEW.
I never quite understood why SSS was removed from the pallet, because when I DECIDE to use it, I DO HAVE MY GOOD REASONS, and I just hate to be forced to place a FSS and then replace it with a SSS.
@GYC: same reason we put safety lids on medicines and rat poison on a high shelf: it keeps stacked sequence out of the hands of those who don't know any better. 🙂
@wiebe: if there were no good reasons, we'd have removed it entirely.
As a Product Owner for LabVIEW, I would not approve using block diagram cleanup for this type of refactoring operation, so I'm declining this idea.