LSL Style Guidelines

These are proposed guidelines for how we should standardize our LSL coding, loosely based on a combination of the Second Life Style Guide here: http://lslwiki.net/lslwiki/wakka.php?wakka=Styleguide ...and the Moodle guidelines here: http://docs.moodle.org/en/Coding

Currently our code does not particularly follow these guidelines, or any others...

Functions

Function names use lower_case_separated_with_underscores.
Functions that will be shared (ie. duplicated) between different sloodle scripts should be prefixed sloodle_ (eg. sloodle_my_function) and documented on the Shared LSL functions page.

Variable names (except for constants) should be all-lowercase, without underscores, like Moodle.
Constants should be UPPER_CASE_SEPARATED_BY_UNDERSCORES, like Moodle.
Wherever possible, the same variable names used in Moodle scripts should be used in LSL scripts. These should also be the names of parameters used to pass data to Moodle.
Unlike Moodle, global variables in LSL scripts should not be upper-case. (This is because if passed to a Moodle PHP script, they will probably not be global in the Moodle script.)
Unlike normal LSL best practice, global variables (other than constants) won't be specially marked as such by putting them in capitals or prefixing them with "g". (Also because they're probably not going to be global in Moodle PHP scripts.)
Variable names don't tell you what kind of variable you're using, so we don't use things like integermyvariable - unless you have two variables that mean the same thing but are different types.
Variables which have the same meaning in a number of different sloodle objects are prefixed with sloodle (variables), or SLOODLE_ (constants). Their meanings should be documented on the Sloodle variables page.
Global constants defining channels begin with SLOODLE_CHANNEL_AVATAR_CHAT, SLOODLE_CHANNEL_AVATAR_DIALOG, SLOODLE_CHANNEL_OBJECT_CHAT, etc. Their meanings and values should be documented on the Sloodle channels page. Other families of related constants should follow a similarly predictable naming scheme.

Always enclose blocks in curly brackets, as per the LSL guidelines.
Opening brackets for functions and states should start on the line after the function / state declaration. Otherwise, start on the same line.

TODO: Specify which checkboxes you need to check in SL to accomplish this.

Possible exception: If prim-passwords are still to be used, educators will need to redistribute no-mod scripts (but will need access to full perm scripts). We do hope to phase out the need for prim-passwords, however. Daniel

TODO: Write an example script demonstrating all of the above.

Edmund Edgar, 2007-06-06