As I’m going forward with the community scripts project, I figured it’d be smart to get some coding conventions set up for it. I could do this arbitrarily, but I suppose it could also be useful to generate a dialog we all can benefit from. What we come up with here will eventually be formalized into coding conventions for the community scripts. I will keep an up-to-date list of agreed standards on [w]TAO:Code Conventions[/w]
I can only really cover maxScript and HLSL since that is what I’m familiar with. And I don’t think Python will be much of an issue since its formatting is pretty rigid 
Remember the code for highlighting is [noparse]
[/noparse] (replace mxs with mel, python, or hlsl)
[legend]MAXScript[/legend]
[ul]
[li]For single line program flow statements, either go to the next line and indent after then, or put in brackets. For example:
[/li]
if a == b then
print "This is fine."
else if a == c then
(
print "This is fine also."
)
else if a == d then print "This is not fine!"
else print "This may be fine, since it is an else, your call."
[li]Parenthesis should be at the same indentation as the code outside of them, NOT indented to be with the code inside of them. This is the default behavior of the MXS Pro-Editor and should be standardized.
[/li]
if true then
(
print "Proper indentation"
)
else
(
print "Improper indentation"
)
[li]counter for loops should be ‘for i = 1 to num’ as opposed to ‘for i in 1 to num’
[/li][li]Restrict use of global variables. This itself deserves an entire article, I think, but please restrict your use of globals, people reading and debugging your code will thank you. You should never use globals to keep track of rollout UI control values unless there is really no other option- instead, declare the rollout as a global and refer to the values of the controllers (rollout.control.value, for example). If I can’t find a good article about restricting use of globals, I’ll write one myself. If you must use globals, give them a good long prefix, so there will be no conflicts, and you will be discouraged to type them out (the latter is the main reason )
[/li][li]Declare your variable scope. When you are completing code, make sure you declare the scope of your variables explicitly (with ‘local’ or ‘global’). It makes everything much easier to read and debug.
[/li][li]Iterate for loops with i, j, k, etc.
[/li]
for i = 1 to 10 do
for j = 1 to 10 do
for k = 1 to 10 do
print (i + j + k)
[li]Don’t use parenthesis needlessly. Especially in for/while/if statements, where you are comparing clauses… MXS is usually smarter than we give credit to in how it evaluates these, you don’t need to type 'if (a == b) then…, use these parenthesis the same way you would use them for math. ie, you would type 'a = b + c + d, not 'a = (b + (c + d))’, yet I see wasted parenthesis a lot. Just be smart with them, the MXS help is there to provide you with details on how Max evaluates comparison operators.
[/li][li]Tabs, not spaces. I shouldn’t have to say that, though.
[/li][li]Read “How To Make It Faster?” area of the MXS Help (thanks Bobo!). Most of the stuff here will be functions, so they should be optimized well… this area of help is one I have read many times over until I’ve memorized it and I have had countless applications for it, learn it!
[/li][li]Balance optimizations with readibility. Since MXS performs no optimizations, it can be quicker to pack all your statements into as few variables as possible… however, this can be difficult to read. It may be worthwhile to provide an ‘expanded’ version in commented code for learning/debugging/evaluation purposes.
[/li][li]Comment your code. I am such a hypocrite 
But ideally lots of people will read, use, and learn from your code, so the comments will actually benefit people, even if you don’t get hit by a bus.
[/li][/ul]
Disagree? Let me hear it! I don’t always follow this in my code, but if I’m writing stuff others will likely have to read or get into I try to follow it.