Difference between revisions of "LSL Style Guide"

From Second Life Wiki
Jump to navigation Jump to search
Line 53: Line 53:
     key OWNER_KEY = llGetOwner();
     key OWNER_KEY = llGetOwner();
</pre>
</pre>
==Separating Code==
Many people will start out doing many, many function calls on one line. This makes the code hard to read, and almost impossible to debug. The following is an example of one such program:
<pre>
default {
  touch_start(integer n) {
      integer i = 0;
      integer index = llListFindList(lst, [llToLower(llGetSubString(llList2String(llParseString2List(llKey2Name(llDetectedKey(i)), [" "], []), 0), 0, numDigits+-1))]);
      if (!llListFindList(lst, [llToLower(llGetSubString(llList2String(llParseString2List(llKey2Name(llDetectedKey(i)), [" "], []), 0), 0, numDigits+-1))]));
          lst += llToLower(llGetSubString(llList2String(llParseString2List(llKey2Name(llDetectedKey(i)), [" "], []), 0), 0, numDigits+-1));
      llOwnerSay(llList2CSV(lst));
  }
}
</pre>
Now here is the code, with the exact same features, in a simpler way. While hardly anyone could tell you what the above code did, almost everyone can tell you what the below code does.
list lst;
integer numDigits = 10;
default {
    touch_start(integer n) {
        integer i = 0;
        string name = llKey2Name(llDetectedKey(i));
        list nameAsList = llParseString2List(name, [" "], []);
        string firstName = llList2String(nameAsList, 0);
        string startPart = llToLower(llGetSubString(firstName, 0, numDigits+-1));
        integer index = llListFindList(lst, [startPart]);
        if (!index)
            lst += startPart;
        llOwnerSay(llList2CSV(lst));
    }
}


==Script Structure==
==Script Structure==
LSL scripts are comprised of expressions, functions, statements, event handlers and states. The LSL compiler mandates a certain structure to scripts:
LSL scripts are comprised of expressions, functions, statements, event handlers and states. The LSL compiler mandates a certain structure to scripts:


#User defined variables and functions
#User Defined Variables
#[[default]] state
#User Defined Functions
#[[default]] State
#User Defined States
#User Defined States
===Indentation===





Revision as of 13:18, 16 August 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. Once a scripter is the practice of using a particular style, reading code in that style will be easier. Consistent indenting makes reading both styles easier. In Method One indenting is the key indicating factor of levels of scope.

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();


Separating Code

Many people will start out doing many, many function calls on one line. This makes the code hard to read, and almost impossible to debug. The following is an example of one such program:

default {

   touch_start(integer n) {
       integer i = 0;
       integer index = llListFindList(lst, [llToLower(llGetSubString(llList2String(llParseString2List(llKey2Name(llDetectedKey(i)), [" "], []), 0), 0, numDigits+-1))]);
       if (!llListFindList(lst, [llToLower(llGetSubString(llList2String(llParseString2List(llKey2Name(llDetectedKey(i)), [" "], []), 0), 0, numDigits+-1))]));
           lst += llToLower(llGetSubString(llList2String(llParseString2List(llKey2Name(llDetectedKey(i)), [" "], []), 0), 0, numDigits+-1));
       llOwnerSay(llList2CSV(lst));
   }

}

Now here is the code, with the exact same features, in a simpler way. While hardly anyone could tell you what the above code did, almost everyone can tell you what the below code does.

list lst; integer numDigits = 10;

default {

   touch_start(integer n) {
       integer i = 0;
       string name = llKey2Name(llDetectedKey(i));
       list nameAsList = llParseString2List(name, [" "], []);
       string firstName = llList2String(nameAsList, 0);
       string startPart = llToLower(llGetSubString(firstName, 0, numDigits+-1));
       integer index = llListFindList(lst, [startPart]);
       if (!index)
           lst += startPart;
       llOwnerSay(llList2CSV(lst));
   }

}


Script Structure

LSL scripts are comprised of expressions, functions, statements, event handlers and states. The LSL compiler mandates a certain structure to scripts:

  1. User Defined Variables
  2. User Defined Functions
  3. default State
  4. User Defined States


Editor

There are many 3rd party editors with LSL syntax files. See LSL Alternate Editors for more information.