Talk:LSL Style Guide

Changes to the Style Guide

I would like to propose that any amendments to the style guide page should FIRST be discussed and approved by others here in this discussion page. Otherwise we can have individuals imposing their eccentric practices willy-nilly. Omei Qunhua 04:35, 24 December 2013 (PST)

Yeah. The latest change is a prime example of this. It will take some work to neuter it. I don't want to outright revert it. -- Strife ^{(talk|contribs)} 19:22, 6 September 2014 (PDT)

Reverting it is a good starting point. From there, the additions can be discussed, as they should have been in the first place, and the relevant parts added. --Pedro Oval 10:33, 7 September 2014 (PDT)

Script Formatting

I've recently looked more at ways to keep SL scripts easily readable, and I found that good formatting can be a very positive influence on readability. Would it be worthwhile to advertise it? basic example:

integer number = 14;
string something = "test";

and instead, with formatting:

integer number    = 14;
string  something = "test";

I personally find this a lot faster to take in, and this might be good to pick up for the wiki, possibly making the code pieces here easier readable for the beginning scripter. especially the article on variables has a block of definitions right at the start, for example, which is a bit confusing to read, but significantly improved by formatting - compare to earlier versions, I went and formatted the text, which, imho, greatly helped readability in that particular case. feel free to revert if theres issues, I consider it a good improvement however, and wouldnt mind bringing more articles to that kind of formatting style if its approved on. its a thought i wanted to throw in here, and might improve the experience for the readers in general.

Psistorm Ikura 15:28, 15 April 2009 (UTC)

I agree with the above,and illustrate it further here, tho' I would have my doubts that others could be persuaded to follow suit. Rigorous alignment makes it so much easier to take in the code's effects quickly. I also prefer to have a space following any comma, for readability.

string    name    = "The Name";
integer   index   = 1;
list      days    = ["Mon", "Tue", "Wed", "Thu", "Fri", "Sat"];
rotation  MyRot;


    if      (msg == "Vol+")          ++gVol;
    else if (msg == "Vol-")          --gVol;  
 
    else if (msg == "Red")           gColour = <1, 0, 0>;
    else if (msg == "Green")         gColour = <0, 1, 0>;
    else if (msg == "Blue")          gColour = <0, 0, 1>;

Omei Qunhua 04:35, 24 December 2013 (PST)

Space following comma: Good. Putting your conditional execution blocks on the same line as your condition: THE GOGGLES! THEY DO NOTHING! I just find the latter makes my brain itch. It complicates the parsing for me. That said, it's a personal preference thing... and I would have trouble not going through and putting them on their own line. -- Strife ^{(talk|contribs)} 01:43, 25 December 2013 (PST)

But it's soooooo beautiful! Like a mini-database, the columnar nature giving it such regularity, such clarity, such a poetic architectural feel! The format you wants breaks up the logic unnecessarily, confusing the eye. But then ... I've only been programming for 52 years. (I have to pull that one out from time to time ^^ ) Omei Qunhua 16:16, 26 December 2013 (PST)

It makes me think of Basic when I see it (QBasic actually) where THEN is like "{", and ENDIF is like "}". If there wasn't a new line following your THEN you don't need an ENDIF and you give the appearance of an unclosed block.

I've come up with a reason for why I shouldn't like it. It has to do with Order of Execution in LSL, which is to say, it is backwards. Every other language I have seen executes the left operand first and then the right, LSL is the complete opposite, which means that you execute statements right to left. If your expression has side-effects, they will happen in right to left order (though a literal list elements expressions and function parameter expressions are executed in left to right order (though the actual execution of each expression is still executed in right to left order)). This means a paranoid LSL scripter reads their expressions right to left, and if you place two expressions on the same line, you run the risk of reading the later expressions before it should be read. I don't think (but I could be wrong) this really describes how I work. -- Strife ^{(talk|contribs)} 23:45, 26 December 2013 (PST)

Script Structure

Mandating event order seems a little retentive to me. I don't think any scripter who is going to post code onto the wiki is going to be keen on rewriting their code to fit the pattern. Being flexible to other scripters styles is a key to success (especially with regards to collaborative projects). They should be grouped in a fashion that makes sense to the script and scripter. Seeing as this section is going to be a hot topic, maybe it shouldn't be included or make it very short? Strife Onizuka 22:29, 14 February 2007 (PST)

I agree that mandating event order would be a pain in the ass.

I personally put events in the order they're first used throughout the process of a script's life cycle.

If a Resident is learning to script from a mentor or teacher, they're likely to be using snippets of code they're sent in-world. For them to see a different structure in LSL Library code would be confusing

SignpostMarv Martin 05:44, 15 February 2007 (PST)

Residents start with the default "Hello World" script with touch event. Finding the Wiki examples at odds with that script (through the use of PUBIC_CHANNEL for example) will be confusing for them The Wiki should follow the pattern of the vast majority, unless it's clearly wrong in some way. Omei Qunhua 04:35, 24 December 2013 (PST)

Re: General Guidelines

Would suggest that the virtues of the second style shown be amended. Saving space is a pointless exercise if LSL code is truly compiled rather than interpreted. The overhead needed to compile a few extra carriage returns has to be trivial in all but the most monumentally huge scripts.

Second virtue of the "parallel brackets" style (the second type shown) is that the nesting of logical modules is far more clear, and is effectively a form of self-documentation that is often more effective than text comments, especially when code is likely to be rewritten, revised or adapted to another purpose by individuals other than the original author. It can even help the original author understand her own code better, faster, if she is returning to a bit of code written in the relatively dim past.

Would take a shot at saying this more concisely, but first want to see if there are other views that should also be reflected in any revision to the text.

This is my first contribution here. Please forgive any unintentional breeches of protocol and etiquette. --Azadine Umarov 17:49, 7 May 2007 (PDT)

Good comment. Bracketing style is an old debate in programing (20 years at least). Both styles have their advantages as long as the scripter is consistent with the style they pick. The key in programing is consistency in style, not so much what the style is. -- Strife Onizuka 12:11, 8 May 2007 (PDT)

I wonder if we should just show the two ways of bracketing and let the readers decide which to use, with out giving any description of which one is "Better", even though everyone knows the brackets go on the same line as the code. ;P Xaviar Czervik

Some of my pet peeves with this article...

Hey there, fellow LSLwiktors!

So, I've done the unthinkable: edited the Style Guide without discussing it first. 😅

Rest assured, everything is just a simple revert away. Also, essentially, I get annoyed by an article being flagged for using the obsolete <source> tag, so I simply change it to the current <syntaxhighlight> tag instead. Why? Well, I actually like the <source> tag more. Long story, but I come from the days when SGML/HTML tags were about structure, not visual rendering — <source> describes the content within those tags (it's source code!), while <syntaxhighlight> implies a specific type of rendering; it would be something to avoid in Ye Olde Days and banned to the Corn Field together with the <blink> tag and similar Cthulhuesque abominations.

Colon after section headers

Personally, I dislike the colons at the end of some of the headers; they look terrible on the ToC. But this is a matter of personal opinion. So, I suggest that either all headers have colons at the end (for consistency's sake), or none have colons, just like all other headers in the Wiki. A third alternative would be disabling the ToC, to get rid of those annoying violation of æsthetic rules...

Use third party editors

Regarding this section, I propose a very slight (but reasonable!) change, namely, adding that one advantage today of 3rd-party editors is that it's far easier (and faster) to edit long sections of code, and just keep loading and saving the file from/to the local disk.

Under the Firestorm Viewer, it's even better — you can open the script directly on an external editor, and, when saving, you get a button to save directly to that external file; conversely, you can do all your edits on the external editor, and, when saving, those changes will immediately reflect on the in-world LSL script (at least, that's the result from my experiments).

The ability to integrate with a 3rd-party editor so closely means that, in areas with high lag, you can continue to do all your scripting in the external?? editor — thus, not being subjected to the fickleness of the built-in LSL editor, which will become more and more lagged, so far as conditions continue to deteriorate in the region. It takes not much lag to reach a certain threshold that makes scripting inside SL a prefect nightmare... while external editors, of course, are not affected by in-world lag.

LSL lacks an optimizing compiler.

Are we really sure about this? It's just because that LL originally used their own, home-grown interpreter/compiler for LSO bytecode, which was deemed not to be very good at its job. Nowadays, however, I would say that the Mono compiler makes a respectable job of optimizing things, and, as such, this comment should be revised/redacted.

Fixing old-style <lsl> tags in the comments section

I felt tempted, for more than once, to break the Wiki taboo of 'never changing someone else's comments', but decided to ask first. :)

Here is my dilemma: on this talk page, there are a few examples that are of historic value, they came from the earlier Wiki, which used the tag <lsl> to do the syntax highlighting. This tag does not work anymore under the current MediaWiki version. As a consequence, those examples, which illustrate some formatting styles, are next to unreadable.

I therefore propose to (exceptionally) allow these to be edited in order to show those lines of code in context, formatted according to what the original intention of the commenter was. But this is a violation of the trust they placed in the community, that nobody would change their comments, no matter what.

What do you think?

— Gwyneth Llewelyn (talk) 02:37, 15 April 2022 (PDT)

I'm neutral about most of your post and won't comment on it. Things have changed since Linden Lab made the wiki closed due to a fierce spam attack some years ago, and there's very few people remaining to enforce any rules. I totally agree that editing <lsl> tags is clearly an exception to the rule not to edit anyone's comments; I've gone ahead and made that change.

What I can tell you for sure is that LSL does indeed lack an optimizing compiler. That's the very reason why LSL-PyOptimizer exists. It optimizes for size only and is designed for Mono only; for LSO it can make programs grow instead of reduce in size, or even stop working due to triggering LSO bugs. The point is that Mono is definitively affected. I studied Mono bytecode in depth while writing the optimizer, and was horrified by what I found.

Linden Lab's compiler generates bytecode for basically everything you write, except labels. Even the names of global variables, functions, events, parameters or states use up code memory; only the names of local variables and labels are free from that madness. Given the 64KB limit imposed to Mono scripts, saving memory is crucial for some applications.

Anyway, the example about optimization vs readability is crap and I'm going to edit it. It declares a variable and then uses it without assigning any value to it; it assigns a long expression to another variable that it doesn't use either, and repeats a long common subexpression twice that anyone would realize is wasting, rather than saving, memory. It also uses llKey2Name(llDetectedKey(x)) instead of llDetectedName(x); if it's an example of the loss of readability when optimizing code, it's not a good example of such optimization.

--Sei Lisa (talk) 04:33, 12 June 2022 (PDT)