Difference between revisions of "LSL Style Guide"

From Second Life Wiki
Jump to navigation Jump to search
Line 5: Line 5:
==General Guidelines==
==General Guidelines==


Most people, when they start programming by their self, will have programs that are UGLY to look at; to put it nicely. They usually look like the following:
Most people, when they start programming on their own, will have programs that are UGLY to look at; to put it nicely. They usually look like the following:


     default {state_entry(){llSay(0,"Hello World.");}}
     default {state_entry(){llSay(0,"Hello World.");}}


However, that code is impossible to read when one is making a ten thousand word program. Therefore, programmers have two main methods as two bracketing.
However, that code is impossible to read (or at least to ''follow'') when one is writing a ten thousand word program. Therefore, programmers have two main methods as to bracketing.




Line 32: Line 32:




Method one conserves space, however method two is easier to read for the beginner.
Method One conserves space, however Method Two is easier to read for the beginner.
 
Method Two has the added benefit of more clearly showing the individual, logical modules within the program, at least in most instances.  While it is not a substitute for clear and concise programmer comments, consistent use of the clearest format can often serve in itself as a form of "comment" or at least clarification of what the program is meant to do.  Such practice may also help the programmer when it comes to debugging a work in progress, or reworking a long-forgotten bit of code.


==Naming Conventions==
==Naming Conventions==

Revision as of 17:58, 7 May 2007

Effective programming in LSL requires that developers use a disciplined practice for applying formatting and convention to their scripts.

These guidelines, referred to collectively as a Style Guide, are not as rigid as the rules required by the language compiler but nonetheless are critical to creating maintainable code. The most critical aspect of a style is that you apply it consistently to the code you write.

General Guidelines

Most people, when they start programming on their own, will have programs that are UGLY to look at; to put it nicely. They usually look like the following:

   default {state_entry(){llSay(0,"Hello World.");}}

However, that code is impossible to read (or at least to follow) when one is writing a ten thousand word program. Therefore, programmers have two main methods as to bracketing.


Method One:

   default {
       state_entry() {
           llSay(0, "Hello World.");
       }
   }


Method Two:

   default
   {
       state_entry()
       {
           llSay(0, "Hello World.");
       }
   }


Method One conserves space, however Method Two is easier to read for the beginner.

Method Two has the added benefit of more clearly showing the individual, logical modules within the program, at least in most instances. While it is not a substitute for clear and concise programmer comments, consistent use of the clearest format can often serve in itself as a form of "comment" or at least clarification of what the program is meant to do. Such practice may also help the programmer when it comes to debugging a work in progress, or reworking a long-forgotten bit of code.

Naming Conventions

There are many naming conventions in Second Life. Only the most used ones will be listed below.


Global Variables (variables used through out the entire program) should begin with a lowercase g. For Example:

   integer gSelected = 0;
   string  gMyName = "Please set one";


Variable Constants should be in ALL CAPS. For Example:

   integer CHAT_CHAN = -517265;
   key OWNER_KEY = llGetOwner();

Script Structure

LSL scripts are comprised of expressions, functions, statements, event handlers and states. A well formatted LSL script follows this structure:

script variables

user defined functions

states, beginning with default, then listed alphabetically

within states, event handlers, in this order

on_rez state_entry

touches / collisions touch, touch_start, touch_end, collision, collision_start, collision_end, land_collision, land_collision_start, land_collision_end

communications listen, link_message, dataserver, email, remote_data, http_response, no_sensor, sensor, run_time_permissions, control

inventory changed, object_rez, money, attach

movement moving_end, moving_start, at_rot_target, at_target, not_at_rot_target, not_at_target

other

timer, state_exit

Indentation

Editor

One of the best text editors i have found is text pad ( textpad_site )


Syntax Highlighting

I have created a syntax file that works well syntax file To customize syntax highlighting for Second Life LSL:

1. Choose Preferences from the Configure menu, and the Preferences dialog box will be displayed.

2. Click the "+" next to Document Classes.

3. Click the "+" next to the document class you want to modify.

4. Select Syntax.

5. Check "Enable syntax highlighting".

6. Select a suitable syntax definition file from the list.( sim.syn )

7. Click Apply or OK.