Difference between revisions of "LSL 101/Comments, White-space and Formatting"

From Second Life Wiki
Jump to navigation Jump to search
(New page: Here's another valid LSL script. <lsl> // This is a valid, but horribly written, script default{state entry(){}} </lsl>)
 
m (<lsl> tag to <source>)
 
(8 intermediate revisions by 3 users not shown)
Line 1: Line 1:
[[Category:LSL 101]]
{{NavNextPrev|prev=Simple Script Skeleton|next=Event Handler Parameters}}
{{LSL Wikibook Index}}
Here's another valid LSL script.
Here's another valid LSL script.
<lsl>
<source lang="lsl2">
// This is a valid, but horribly written, script  
// This is a valid, but horribly formatted, script  
default{state entry(){}}
default{state_entry(){}}
</lsl>
</source>
The first line is called a '''comment'''.  Anything following // on a line is ignored by the computer.  Comments are intended solely for the human reader of the script.  Since a successful script will invariably be read by humans, it's just as important to make them understandable to humans as to the computer that is going to execute them.  In general, the most useful comments are those that explain the script on a higher level than the individual LSL statements.  An explanation of what a section of script is intended to do is much more helpful that a line-by-line translation of LSL commands into English.
 
Sometimes you might hear "really awesome scriptors" make some comment like "my code is my commentary," and when you get to the level that it reads like English to you I am sure that is so.  For the rest of us, there are comments.  Leave many and you will save redebugging your own code later when you've long since forgotten what you did. 
 
The second thing this script illustrates is that '''white space''' characters (blanks, tabs and separate lines) are, for the most part, entirely optional.  They can be added or removed without changing how the computer executes the script.  The major exceptions are 1) a new line always ends a comment and 2) you can't insert a space or tab in a name or number.  For example, you can't write
<source lang="lsl2">
    // These are NOT valid LSL fragments
    state entry    // This would be interpreted as two separate names
    123 456        // ... and this as two separate numbers.
</source>
 
A generous use of comments and white space can make a script much easier to understand.  When you first start writing scripts, you probably won't think that's very important.  But the first time you go back and try to read your ''own'' script after being away from it for a week or two, you'll start to appreciate how important good comments and formatting are.  And you don't save anything significant by being parsimonious.  The form of the script that is actually executed (called the '''compiled''' version) has all the comments and white space removed, so they don't cause the script to execute any slower, or take up any extra memory.
 
'''Click on [[LSL 101/Event Handler Parameters|Event Handler Parameters]] to continue the tutorial.'''

Latest revision as of 12:39, 24 January 2015

← Simple Script Skeleton ↑̲  LSL 101  ̲↑ Event Handler Parameters →

Here's another valid LSL script.

// This is a valid, but horribly formatted, script 
default{state_entry(){}}

The first line is called a comment. Anything following // on a line is ignored by the computer. Comments are intended solely for the human reader of the script. Since a successful script will invariably be read by humans, it's just as important to make them understandable to humans as to the computer that is going to execute them. In general, the most useful comments are those that explain the script on a higher level than the individual LSL statements. An explanation of what a section of script is intended to do is much more helpful that a line-by-line translation of LSL commands into English.

Sometimes you might hear "really awesome scriptors" make some comment like "my code is my commentary," and when you get to the level that it reads like English to you I am sure that is so. For the rest of us, there are comments. Leave many and you will save redebugging your own code later when you've long since forgotten what you did.

The second thing this script illustrates is that white space characters (blanks, tabs and separate lines) are, for the most part, entirely optional. They can be added or removed without changing how the computer executes the script. The major exceptions are 1) a new line always ends a comment and 2) you can't insert a space or tab in a name or number. For example, you can't write

     // These are NOT valid LSL fragments
     state entry     // This would be interpreted as two separate names
     123 456         // ... and this as two separate numbers.

A generous use of comments and white space can make a script much easier to understand. When you first start writing scripts, you probably won't think that's very important. But the first time you go back and try to read your own script after being away from it for a week or two, you'll start to appreciate how important good comments and formatting are. And you don't save anything significant by being parsimonious. The form of the script that is actually executed (called the compiled version) has all the comments and white space removed, so they don't cause the script to execute any slower, or take up any extra memory.

Click on Event Handler Parameters to continue the tutorial.