I have had dubious results with flowcharts of production programs ... but perltidy is quite a different matter. A 4,000-line program is “of moderate size,” at best, but it is still big enough to be difficult to understand if it is inconsistently (un?)documented or formatted. “Tidying up” the source-code by automatic means, so that the block structure etc. is reflected in the indentation of the source listing, can be a big boost in visual comprehension. Our eyes are very tuned toward the detection of patterns and the exploitation of visual consistency. When we have that, we can see things “at a glance.”
| |
My experience with other languages is that machine generated flow charts are seldom useful for anything but satisfying a customer requirement for a flow chart. They must be isomorphic with the code. This is not at all the same as a hand drawn chart, where its designer comunicates his understanding of the code (often by intentionally omiting details.)
I believe that formatting your code with the CPAN utility perltidy would be more useful than rearranging the code into a flow chart. Clearly, this is a matter of opinion which you must decide for yourself.
| [reply] |
| [reply] |
You can even involve sqlt, after all UML is schema :)
| [reply] |
Flow charts can be an excelent way to document our understanding of a program. No utility can possibly do this for us. Use any tool(s) that you find useful.
I suggest perltidy as a substitute for a flow chart program only in the sense that both are intended to reveal the structure of the code. I find it easier to grasp that structure from systematically indented code rather than from machine generated charts which spread the same information over several times as many pages. Again, my advice is use what works for you!
| [reply] |
A search on CPAN showed chart modules
| [reply] |
I was looking outside, instead of looking on CPAN, thank you.
| [reply] |