Hallo, Trevor Agus hat gesagt: // Trevor Agus wrote:
Has anyone seen rules-of-thumb for "good PD programming practice" (in the same way "Extreme Programming" has advice for good C++ writing?) Or does anyone have strong opinions on the topic?
e.g. are abstractions preferable to subpatches, or is there a time and place for each? Is there a recommended limit to objects in any canvas, for clarity's sake? Any recommendation on the extent and style of commenting?
My aim is to have some "house rules" so a number of us can work on the same large-scale patch with maximum clarity and minimum confusion. (Also, it's part of an assignment, so we need to do things as "by the book" as possible.)
This is a very interesting bag of questions, and you surely will not get final answers shared by everyone on this, as Pd is so open and free-form, that there will never be a common ground among all users for it, and there also are so many different useages of Pd.
This isn't a bad thing at all.
Still, thinking about these issues IMO is an essential part of working with Pd. I only came to realize this after 3 or 4 years of Pd usage. It will help a lot to read as much as possible about design questions in related areas. By this I mean for example design methods in software development, like the object oriented approach, and also some GUI guidelines like the Apple interface guidelines. This is really enlightening stuff.
The concrete example questions you asked are actually minor issues in that context. Like: abstractions and subpatches are totally different things that have a very different semantics inside patches. Subpatches have no real meaning (at least not much) besides making room inside a patch, wheras abstractions are a statement made by the developer saying: "This is standalone functionality. I might use this again later, and you are encouraged to do so as well." Also what is clarity is more a matter of taste and personal preferences.
A thing, that really *is* important is for example how you design the communcation paths insider your patch. When do you use a simple send/receive, and when do you use a network transparent OSC connection? Which parts of your patch should talk to or even know about which other parts? How many things do you want to control as a patch user, which things are better controlled by some random automatic function? And might this change later?
Those are questions, that really force you to make the interesting decisons.
So, maybe the "non-Extreme Programming" advice I would give is: "Sit down and think, before you patch." Actually I got this advice once from Kim Cascone, who said it in a slightly other way like: "Make a detailed plan before you develop something and by all means: Stick to it!" The last part is the hard part.
I might add, that personally I still cannot follow this rule, but I'm working on it. ;)
ciao
Frank Barknecht _ ______footils.org__