[PD] Good PD programming practice?

[Frank Barknecht]

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__