Re: auto creation of flow diagrams
- From: LV_Pro <x@xxxxxxxx>
- Date: Wed, 4 Jul 2007 15:40:07 -0500 (CDT)
I'm going to jump into the discussion, as one who has had to both
figure out a lot of code written by others, in a variety of "style" and
techniques, and frequently tasked with documenting this code. As Mike
stated, flow charts, as such, are not very useful in trying to describe
complex programs. As to how easy it might be for a charting program to
document the flow of a program, it wouldn't for most LabVIEW programs,
other than some very basic, written linearly (think flat sequence
structure) ones. While LabVIEW has been called a "data flow language" I
would propose that it has evolved past that. While parts of a program
will still be subject to data flow, with vi's not executing until all
of their inputs have received data from "upstream", it really doesn't
describe some of the structures that those may be parts of. Flow
charting a multi-sourced queue based program would be non trivial. As
to a documentation program understanding the flow, well I've seen some
really bad code, with stuff flowing all over the place with locals,
globals, etc. Charting it would have resulted in something that would
look like those pictures of the webs of spiders given LSD.
While Mike might have been a little strident in his response ("after
all, he's not a tame Lion"), it sometimes is our job to do annoying
tasks, annoying because they are so much more difficult and time
consuming when done after the fact, particularly when you weren't the
original programmer and you are having to figure out what and why the
original programmer did what ever they did, and
whether it was the correct thing to do. As the principal in a small
consulting firm, I have to do this all the time, frequently with code
that was written by very inexperienced engineers, and it isn't fun. But
it sometimes it is the job. If you can find, or write, a program to do
what you suggest, a lot of programmers would be interested. As to how
easy, well National Instruments took a long time to come out with their
VI Analyzer tool, which basically checks the code for stylistic issues,
which allows a pretty definable set of rules. Given the almost limitless techniques employed
in writing a complex LabVIEW program the real answer is, modularity
(break up functions into smaller, more understandable functions) and
documentation at development time. The first allows the description to be pretty high level for the main part of the program, and then the individual parts can be more easily described, well, individually. The later is pretty critical, as
sometimes the original author may have a hard time remembering why a
piece is coded a certain way (then again, it may just be me, there is a
reason I use a "trilobyte" icon). As Altenbach said, 5% creative, fun stuff, 95% the rest of the task.Message Edited by LV_Pro on 07-04-2007 04:25 PM
.
- References:
- Re: auto creation of flow diagrams
- From: altenbach
- Re: auto creation of flow diagrams
- Prev by Date: Re: How can I abort a running VI if I have no menus
- Next by Date: Out of memory on application build - what to do ?
- Previous by thread: Re: auto creation of flow diagrams
- Next by thread: Re: auto creation of flow diagrams
- Index(es):
Relevant Pages
|
Loading