[PD] "Structured" dataflow?

Andy Farnell 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
related function.

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
abstract it.

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...
> marius.
> 
> 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 mailing list