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: <lsl>integer number = 14; string something = "test";</lsl> and instead, with formatting: <lsl>integer number = 14; string something = "test";</lsl> 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.

<lsl> 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>;

</lsl> 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