flowcharting is automatic for Python via preprocessor

[Richard Hilburger]

As I read your comments, I found myself agreeing with each point.  I feel
that your analysis is quite good.  I get the drift of your example at
http://oregonstate.edu/~barnesc/temp/flow.pdf   Well done.  My detailed flow
diagram is indeed "visually busy".  After all, it shows every path leaving
no room for misinterpretation.  Your diagram method is like a shorthand
version of my diagram method.  Cleaner in appearance, but requiring more
skill and experience to read it correctly.  A tool such as the preprocessor
I developed could easily have either a command-line flag or a user setting
to let the user choose either detailed or less-detailed flow diagrams.

Integration into a code editor is indeed a worthy goal, and if done well
would very likely improve the appeal of any such methodology.  I had thought
of it, but decided to take an easier approach to test the water first.

Do other editors do this?  I don't know what is out there.  Neil posted:
http://www.eng.auburn.edu/grasp/index.html and I'll have to take a closer
look at that.  At first glance, it looks confusing and unappealing.


<barnesc at onid.orst.edu> wrote in message
news:mailman.1069.1091487166.5135.python-list at python.org...
>
> I like your idea.
>
> It is easy to get lost inside in eg a multiply nested if statement in a
couple
> multiply nested for loops, inside a try block.
>
> Sometimes one can split such code into separate functions, and this makes
the
> code cleaner.  Sometimes not.
>
> However, the real issue is how the eye parses code.
>
> It's really inefficient to scan a whole page of code line by line to
understand
> where loops, branches, continues, and breaks occur.
>
> I think your visual diagrams could help, if they are:
>
> 1. Semantically cleaner.
>    IMO, there is too much detail in the flow diagrams.
>    (See http://www.getcet.org/images/ex3.png).
>
>    A minimal amount of detail is easier to parse with the eye.
>
>    See http://oregonstate.edu/~barnesc/temp/flow.pdf for a cleaner
>    example I came up with.  This doesn't have arrows all over the
>    place (and hence may not be a flow diagram), but it does help
>    point out the relevant control structures.
>
> 2. Integrated into a code editor.
>
>    I could see this being a new code editor fad, like collapsable
>    functions and classes.
>
>    It could be quite useful, if the amount of visual information
>    is kept minimal, so that the coder is not distracted during
>    coding.
>
>    If the flow diagrams are not integrated into an editor, I don't
>    think many coders will use them.
>
> Perhaps editors already do this.
>
>  - Connelly