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?
This is something I have been wondering about lately as well. There seem to be plenty of unwritten rules, but little actual documentation. I think it would behoove the project to set down some guidelines and also supplemental information. For example, "No hard tabs in sourcefiles -- only spaces. Tab depth is two spaces, or one space for curly braces when they are alone on a line." followed by "Here is how you stop emacs from using hard tabs in sourcefiles, and here is how you set the indentation style to be consistent with our own. Here is how you set the same items up in JEdit and here is how you do it in vi." I would be willing to do much of the legwork on this. I have spring break coming up this Friday so I have about a week of spare time to spend on boring detail-oriented assignments such as this. I have spent quite a lot of time looking at the source for Pd and related externals, so my familiarity with the code is well-developed enough that I think I may be able to do a decent job.
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?
Again, more guidelines are needed. As for the extent, I would suggest that anyone contributing code should comment anything they think wouldn't be obvious to an intermediate-level programmer, and also provide decriptive documentation and usage info in a comment in the head of the main source file(s). Perhaps we should adopt something like Doxygen for this stuff?
If anyone thinks I am being a snotty kid, or this has already been done and I am too lame to realize it, feel free to smack me down.
I am going to cross-post this to PD-Dev, where I think it is more on topic.
-John Lamb