Looks good. Some comments on the website:

Programming conventions are important because:

* Hardly any software is maintained for its whole life by the 

original author. * Code conventions improve the readability of the software, allowing engineers to understand new code more quickly and thoroughly.

You should also highlight that conventions allow you to remember what you where doing in your own software when you come back to it after working on other stuff for a while. Even the best forget some of the details of what they were doing before.

Use abbreviations where they are available, such as those provided in the table below. These make the patches less cluttered. A mixture of abbreviated and unabbreviated objects is harder to follow than either wholly one or the other.

The image doesn't match what you are saying here since the image says that using the full names is bad. I often find it useful to use the full names in order to make that object longer, which makes it a more readible division in the code and gives you more room to lay things out cleanly. Since Pd doesn't have the Max-style resizable object boxes, this is the only way that I know how to do this.

.hc

On Sunday, Mar 14, 2004, at 13:09 America/New_York, Trevor Agus wrote:

Thank you very much for your advice on good PD programming practice. The finished "good programming PD practice" is at:

www.earcatching.com/pdconv

This is intended to apply to situations where PD patches are being shared between users. I don't intend to tell you how you should be doing your personal PD programming! Specifically it is for a project in which 4 of us will be working on the same potentially large-scale patch.

It is a partly a summary of advice received, but mostly a dollup of my own reasoning and personal preferences. Feedback is welcomed. I will update it with necessary changes and note any equally valid alternatives.

Cheers,

Trevor

---

PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list