There is a great thread on Cycling 74s site concerning OO and dataflow
styles, dos and donts.
http://www.cycling74.com/forums/index.php?t=msg&th=25272&start=0&...
On Jan 11, 2008, at 9:37 PM, Andy Farnell wrote:
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@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@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-- Use the source
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list