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&rid=0&S=6bc17f0fd0e897fcb6a32801e8ab41ed 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 <[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 _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
