Scripting Your World: The Official Guide to Second Life® Scripting

CHAPTER 1

32

SCRIPTING

STRUCTURE 101

TYPES

VARIABLES

FLOW

CONTROL

OPER ATORS

FUNCTIONS

EVENTS

AND EVENT

HANDLERS

STATES

MANAGING

SCRIPTED

OBJECTS

AN LSL

STYLE GUIDE

SUMMARY

You can also keep track of the expected owner in a global variable, and reset or adapt the script only

when the owner changes:

key gOwner;

default

{

state_entry() {

gOwner = llGetOwner();

}

on_rez(integer p) {

if (gOwner != llGetOwner()) {

llResetScript();

}

}

}

This book contains scripts that use llResetScript() in many different places depending on specic

needs. It's usually needed in an on_rez() event handler; however, one place to never use it is in the

state_entry() handler—it will result in innite recursion.

WARNING

Two LSL functions allow one script to control the state of another script in the same prim:

llSetScriptState(string statename, integer run), which causes a state transition in

the current script to the named state, and llResetOtherScript(string scriptname), which

resets the named script.

AN LSL STYLE GUIDE

"Any fool can write code that a computer can understand. Good programmers

write code that humans can understand."

—Martin Fowler et al, Refactoring: Improving the Design of Existing Code

Effective programming in LSL requires that developers use a disciplined practice for applying formatting and

convention to their scripts. These guidelines 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. We are attempting to make a guideline, not a rigid coding style,

and thus point out things that must be followed to make it compile and things that should be followed to

make your scripts readable. The SYW website describes a variety of tools you can use outside of SL to

help you script, but the principles are important no matter how you write your scripts.

CHAPTER 2

CHAPTER 3

CHAPTER 4

CHAPTER 5

CHAPTER 6

CHAPTER 7

CHAPTER 8

CHAPTER 9

CHAPTER 10

CHAPTER 11

CHAPTER 12

CHAPTER 13

CHAPTER 14

CHAPTER 15

APPENDIC

E

S

33

CHAPTER 1

CLEANLINESS

The most important practice in effective programming is to generate readable code. Readable code is

easier to debug, understand, and maintain. A short snippet that is poorly formatted may be decipherable

later, but a longer program will not be. If you pay attention to your coding style early on, it will quickly

become second nature.

Here is a list of specific suggestions:

r Bracketing: You must always enclose blocks in curly braces. It is a good idea to always use braces,

even for single statements. Opening braces for functions and states should start on the line after

the declaration. Otherwise, place the brace on the same line as the control block.

r Indentation: On the line immediately following an open brace, you should add one indentation,

usually four spaces. Remove an indentation on the line after a close brace.

The two most important guidelines are indentation and bracketing. This code, for example, is not

properly indented:

default{state_entry(){ llSay(0, "Hello, Avatar!"); } touch_

start(integer total_number) { llSay(0, "Touched."); }}

If you look closely, you'll see that it's the same as Listing 1.1—which was much more readable!

NOTE

r Line wrap:PVTIPVMENBOVBMMZTFQBSBUFMJOFTMPOHFSUIBODIBSBDUFST

r Coding styles: In general, don't mix coding styles. When editing code you didn't create, keep the

FYJTUJOHTUZMFPSDIBOHFUIFTUZMFUISPVHIPVU

r Function length: Try to keep functions short and focused. A good rule is that a function longer than a

screen height should be refactored into multiple functions.

r Comments: Use comments to explain what you are doing; however, avoid excessive inline

comments: well-written code should explain itself. Do, however, describe what each function does

in a comment near the top of the definition.

r Variable naming:

r 7BSJBCMFOBNFTNVTUBMXBZTTUBSUXJUIBMFUUFSPSVOEFSTDPSF

r %POhUBCCSFWJBUF4JODFDBTFNBUUFSTx is not the same as X), longer names will cause

signicantly less confusion.

r (MPCBMWBSJBCMFTTIPVMECFHJOXJUIBMPXFSDBTFg; for example, gSelected.

r 7BSJBCMFTVTFEBTDPOTUBOUTTIPVMECFJOBMMDBQTBOEXPSETTIPVMECFTFQBSBUFECZVOEFSTDPSFT

like this: OWNER_KEY

.

r :PVTIPVMEVTFDBNFMDBTFMPXFSDBTFàSTUMFUUFSBOEUIFODBQJUBMJ[FFBDIXPSEGPSWBSJBCMF

names, such as this: myCountingVariable.