"Labviewguru" wrote in message
news:50650000000500000069870000-1023576873000@exchange.ni.com...
> I stopped using sequences when I was developing what turned out to be
> a dynamic and scalable application, that I didn't know was dynamic and
> scaleable at the time. It was a 2-3mb program (one diagram! - must be
> a record...no, wait, I worked on one that was 6!) in and of itself.
> It had about 200 outer frames, with several inner embedded sequences
> of up to 70 frames each.
You went too far. Sequences are fine if you keep them simple. I ordinarily
have a sequence frame to initialize some stuff, another that has the code
that does stuff, and then one more to fix up the outputs. Not hard to
read. I can see if you make many frame sequences or sequences in sequences
(horrors) that it would be bad. But a short sequence can be easier to read
than converting to subvis since you can see the code by changing frame as
opposed to opening subvi and then going to diagram. A one step process as
opposed to two. Now if the code truly is reusable that would add weight to
the subvi argument. But most often subvi's are not reusable. They are
specific to the current application.
> I had several dozen local variables (after I
> figured out what hell using sequence locals was) and was a complete
> waste of my time, and disk space. I rethought the entire project
> (this was my first big LabVIEW program, started 4 weeks after learning
> LabVIEW) and reprogrammed it. Instead of a single 2Mb program, I
> ended up with a hierarchy of about 20 or so subVIs (a lot of the code
> in the sequences was reusable) that only took about 250k!!!! This new
> version was much easier to read, to write, to understand, to modify,
> to scale, and just plain neater.
>
> One thing you must take into consideration about writing your code.
> It really doesn't matter how easily YOU can read the code. What
> matters is how easily someone else can. The general consensus is that
> sequences are a pain in the butt. However; if noone is ever going to
> look at your code, then be my guest. But, one thing to consider: will
> you be able to understand your code a year later, two years later,
> etc.
Agreed 100%. Code gets passed on and future users will be cursing you if
your code is too complex. Simpler beats elegant every time.
>
> If you think of a sequence frame, as it should be, as a function, then
> creating a function solely on a diagram is a bad idea. Sure, its a
> bit more work to create a subVI, or a series of subVIs instead of a
> sequence (and then put the related subVIs into a higher subVI as a
> single subVI on the main diagram, in place of the sequence structure).
> But the rewards are incredible. You have reusable code. You have
> flexible code. You have a central repository for this code. Your
> code is scaleable. You have automated documentation for your code.
>
> There is no blanket policy that says that sequences are bad,
> otherwise, they wouldn't exist (although I have requested NI to remove
> multiple frame capabilities of sequence structures). But the general
> consensus is that sequences hide code, and make reading the code a big
> pain in the butt. What is often overlooked in programming is that
> other developers have to see your code. This oversight often creates
> headaches when others have to see your code.
>
> I am a consultant, and one of my specialties is rescuing projects that
> are overdue, overbudget, and otherwise destined to fail. The common
> element I see in such projects is poor coding. Among the elements I
> see that contribute to this, the use of sequences has to be the single
> biggest hindrance to productivity.
>
> Your perspective on the matter may not afford you the luxury of seeing
> what others have seen. But I guarantee that once you have, you will
> understand how bad sequences can truly be.
>
> I hope this is helpful.
