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 <[EMAIL PROTECTED]> 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. > > > > _______________________________________________ > > [email protected] mailing list > > UNSUBSCRIBE and account-management -> > > http://lists.puredata.info/listinfo/pd-list > > > > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list -- Use the source _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
