here a couple of coding styles are discussed that can be used with the current sc3 distribution.
this is not complete. please add what you think is essential to know. [jrh]

message style)

has the advantage that it can be implemented easily on other platforms
(well if you intend to) say you can do a lot of things from the terminal
app that you can do with sclang. it is the fastest way for sclang to do things
as it takes the least instructions and it safely doesn't change.
disadvantage is that it is not as general, as bus and buffer indices
are always global for one server. nodeID's are not so easy to remember
but I suggest using years (like 1865) which makes ids about as easy as names.
(see http://www.wikipedia.org/wiki/1792 for example)
the main disadvantage for me is that style 1+2 for synths is that
it separates the instrument from its use (which is an advantage in many cases, too).
regarding buffers it fixes the buffer number to a global index, which
does not account for previeously allocated buffers)
one more advantage is that it gives you direct insight of the server functionality.
there is a helpfile for each command (on the swiki) so cmd-j gives you the server command.

object style)

it is less to read and reveals only information that differs from the default
behaviour. Its speed varies on what you do but many tests prove very good results
as long as it is not used for things it is not intended to.
fast granular synthesis is better with messages or dedicated classes.
mixing styles is most definitely possible in many cases.
bus and buffer allocation with objects has the advantage that it gives you
the next free buffer (you could do that in 1) by a request to the server's
buffer allocator)
using object style with jitlib additions like Ensemble can save you some
work in setting and mapping controls.
"everything" in sclang is an object, also the message you send to the server,
so it is just about how many objects get allocated for what reason. Readability
is in my experience very much dependant on habit. (and sympathy for a style, too.)

pattern style)

not to forget this is one very beautifully simple way of doing things.
separation of instrument and player is here the case, too, but it is
very general and valuable. there is some bugs left in there but there are
great things possible to come here, too.
dynamic multichannel expansion of sounds is an advantage, too.

crucial lib style)

one main aim for crucial lib is the idea of a certain productivity workflow.
its main advantage is access (finding code is sometimes tedious) and recombination
of that code. it allows to automatically generate the gui as
well. It isn't necessarily a gui library at all, I do not use its gui presently.
the main disadvantage for me is that it makes a patch dependant on instruments
saved somewhere else, so it lets you create a very efficient productive system,
but in order to give code away, as a more conversational model it would need
a special code renderer (which can be done of course)

jitlib style)

the classes like NodeMap/Ensemble are pretty much object style,
so they do not really count here. also the pattern classes are just
as patterns ar normally.
I use ProxySpace for quick prototyping and experiments as well as
for live coding in different situations. its main aim is to supply
a narrow gap between preparation and output. the advantage is that
it is sparse in code and remembers mappings and settings independant
of content (you could say it is pronominalized). the disadvantage is
that it might encourage people to write inefficient code (just as function.play does)
and I have not yet found a way to make code efficiently reusable.




//functional style mix

(
Instr([\gger], { arg ffreq, env; 
	LFPulse.kr(3, 0, 0.4, ffreq, ffreq*4) * EnvGen.kr(env,doneAction:2) 
});
)

a = Patch([\gger], [56, Env.asr]);
a.play;

s.sendMsg(9, "default", 1998, 0,0);
s.sendMsg("/n_map", 1998, \freq, a.bus.index);

x = NodeProxy(s);
x.source = { LFNoise1.kr.range(300, 400) };
s.sendMsg("/n_map", 1998, \freq, x.index);

z = Patch([\gger], [156, Env.perc]);
z.prepareForPlay;

(
Pbind(
\instrument, z.asDefName,
\out, x.index
).play;
)