[PD] "Structured" dataflow?
padawan12 at obiwannabe.co.uk
Sat Jan 12 03:37:28 CET 2008
I think Marius is right saying there's little formal
advice on visual dataflow structuring. Someone did a "styleguide"
with do's and dont's, but I cant find the link....anyone?
You could apply most of JSD and general software engineering
principles to visual dataflow though.
Cohesion: Keep things together (spacially, per file/abstraction) that have
Coupling: Don't let too many unrelated things hang off the same value
or method (or outlet in Pd)
Factoring: Elmininate redundancies
Abstraction: If you're doing for a third time it's probably time to
Reuse: see abstraction :)
Flow: Don't overuse [send][receive], the wires are like the ordering
of code lines and a Pd program is read downwards (and maybe right to left?)
Comments: Use them, write your code so you can read it in two weeks time.
On Fri, 11 Jan 2008 21:00:30 -0500
marius schebella <marius.schebella at gmail.com> wrote:
> I am not sure, if there are any scholarly articles about structured
> programming style guidelines for visual programming languages.
> I've seen only rules-of-thumb.
> hey, there is not even a "return" command (to a main program?). only
> inlets and outlets. I am not even sure about the analogy of function,
> class, object when comparing C or C++ to a graphical dataflow
> programming language (which pd is?).
> actually, the data is not flowing at all, it is the objects' function
> code that pilgers to the sanctuaries of stored data and accomplishes its
> task there...
> Dudley Brooks wrote:
> > Can anyone direct me to articles on constructing clear, modular,
> > non-spaghetti patches in pd or other visual dataflow languages?
> > Especially if the articles derive their recommendations from theoretical
> > analysis (as with the investigations that led to structured programming
> > in imperative languages), rather than just rules-of-thumb -- although
> > the latter are useful also.
> > Or is some amount of spaghetti unavoidable in dataflow languages,
> > perhaps because it is inherent in the situation being modeled, rather
> > than being an artifact of the language?
> > Thanks.
> > _______________________________________________
> > PD-list at iem.at mailing list
> > UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
> PD-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Use the source
More information about the Pd-list