Yo, On Mon, Jul 28, 2008 at 10:31 PM, Frank Barknecht fbar@footils.org wrote:
Hallo, Luke Iannini hat gesagt: // Luke Iannini wrote:
There are some amazing sets of abstractions being released recently, which has served to highlight the many extant styles of patching. I was wondering if there was interest in establishing a set of guidelines for patching in the vein of PEP 8 for Python; I've found that document to be very relaxing as it is a standardized approach to OCD. More seriously, it greatly helps when reading other people's code or collaborating. http://www.python.org/dev/peps/pep-0008/
I think, it would be important to first collect every possible style element in the wild and document what people are using in reality. That would be interesting. I'm not too much in favour of a style "guide" however. Let people be creative.
Agreed! Regarding the guide, well, no one is going to be kicked out of the community or have their patches burned for not adhering to the styleguide : ). If you would like to be creative in your lettering you are as free as ever to do so.
But, I think many people (including myself) would rather be creative in the functionality rather than the syntax, and for people such as that, they might as well all do the same thing so they don't invent even more arbitrary ways when they didn't really care to do so.
I've begun to collect some of my practices to start things off.
I added where I do things different.
I was hoping we could all lazy-vote the document together in this thread and I'll then compile it into a PdPedia/Pd.info document. So, feel free to object to or replace my propositions.
Style:
- If giving $0 as an argument to an abstraction, it is always first in
the argument list [1]
I often put it last (and it's specified to be that way e.g. in Memento)
My reasoning here is that $0 is probably the most common thing to pass to an abstraction, but abstractions have varying numbers of arguments, so $0 will sometimes be $3, sometimes $2, sometimes $7, and that swings my brain around. Putting it in the first slot means that $1 gains a sort of second meaning as "my parent's $0", which I think is handy.
And, the same memory-assistance applies to my numeric-ordering proposition as well; I usually remember how many arguments an abstraction has better than what order they're in, so when they're all taken from their parent I know it will be [mychild $0 $1 $2].
- When possible, pass parent arguments in numeric order, like [child
$0 $1 $2 other1 other2] etc.
- Sends and Receives are written in camelCase, with "R" appended to
complementary receives (e.g. in GUIs, $0mySlider for the send and $0mySliderR for the receive)
I use the underscore style sometimes but often a simple "dash" style: "r some-thing" instead of camelCase. My reason: It doesn't need any Shift-key-combinations on German keyboards, and I find camelCase hard to read.
When I want to name matching send/receive pairs I use $0-some-s and $0-some-r.
- When prepending $0 to a symbol, only add a "-" to separate it from
another number, like [r $0-1stSend]. Otherwise the symbol should immediately follow, like [r $0mySend].
I always seperate $0 with a $0-dash. $0myGod is easy to misunderstand.
That's all cool, and I think you are in the majority on that. I think I just took camelCase because it reminded me of Smalltalk and Cocoa, which remind me of Pd : ).
Thanks for the comments Luke
- When working with stereo, Left and Right pairs are written with Le
and Ri appended (to distinguish them from an R denoting "receive", above)
Nice idea. I never did that, though.
Ciao
Frank Barknecht _ ______footils.org__
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list