A matter of taste

[Helium Loon]

Hmm.  That seems potentially hazardous.  Jumping to a label within a scoped block (from outside that block) would present all kinds of problems if they are scoped at the event/global level.  Jumping out wouldn't be as big a deal.

 

If Mono/LSL does this, I can't imagine the level of overhead involved in re-establishing the thunks/scopes involved if the label existed inside nested scopes, but was jumped to from outside them........that's got to be a nasty hit.

 

[LepreKhaun]

---

Helium Loon wrote:

Hmm.  That seems potentially hazardous.  Jumping to a label within a scoped block (from outside that block) would present all kinds of problems if they are scoped at the event/global level.  Jumping out wouldn't be as big a deal.

 

If Mono/LSL does this, I can't imagine the level of overhead involved in re-establishing the thunks/scopes involved if the label existed inside nested scopes, but was jumped to from outside them........that's got to be a nasty hit.

 

---

No, not at a global level- just event and function levels.

 

Scoping within code blocks seems to have been "tacked on" and not very well at that. For instance one could, for a time, change states within a function call inside an "if" block. Imagine what that did to the stack. :matte-motes-smile:

[Madelaine McMasters]

---

Helium Loon wrote:

Unlike all the others, I will actually speak to the efficiency/compiler consequences of using a 'block' or compound statement instead of a simple one (when it will suffice.)

 

Do a little research on compiler theory.  One will find that whenever a 'block' opener is found, the compiler introduces a new 'thunk' or stack frame.  This is why variables defined within such a block have scope limited to that block.  It introduces a new stack, and new address references (you can add a label to a 'block', for unconditional branches, etc.)

 

However, a simple statement does not require the creation of a new 'thunk'.  Therefore, from an efficiency/speed viewpoint, using blocks in an IF or ELSE clause when not needed actually degrades the performance/efficiency of the code.  Creating a new 'thunk' requires additional memory, and has setup time.

 

Now, most modern language compilers optimize this anyway.....if only one statement is found within the braces, it will automatically simplify it to the non-enclosed version for compilation.  I'm not certain whether or not Mono does this or not.

 

So, for myself, I will continue to use BOTH formats, as appropriate.  When doing initial coding, I will use the braces everywhere.....then once the function/event/etc is debugged and working, any single-statement blocks will be pulled out of those enclosing braces.

 

---

Hmm.

While the C compiler will declare a new scope upon encountering a block opening and may create a new local namespace pool during compilation, whether that translates into a difference in generated code has been, so far as I've experienced, dependent on the scoping of the variables inside the block. If the compiler finds nothing inside the block that is local, it generates no new stack frame, as all the variables inside the block are already in scope.

Blocks allow you to declare local variables within the new scope, but they don't require it.

[Helium Loon]

Any user function calls within a block would also require a new thunk, since the return address needs to place properly in the execution stack (so things unwind properly.)  So unless the block contains NO references to local variables or global functions (in Mono/LSL, in C/C++ and other languages it gets even more complicated) then the block contents wouldn't require a thunk.  Not sure if built-in functions would also require it.....

 

Analyzing that for a large block could get quite messy.  I'd have to actually look at the Mono compiler code to see how it handles this...... Not sure if it would bother analyzing code that in-depth.  Obviously, modern high-level language compilers do a LOT of optimizing and analyzing.....but I doubt Mono does more than cursory optimization.

 

[Ela Talaj]

In RL software development it is not a matter of taste but a matter of what is written in the company's Code Style Manual   The idea is that everyone would use the same style so code reviews are more efficient. For a sole developer I guess it is a matter of preference (taste).

[Dora Gustafson]

---

Ela Talaj wrote:

In RL software development it is not a matter of taste but a matter of what is written in the company's Code Style Manual

  The idea is that everyone would use the same style so code reviews are more efficient. For a sole developer I guess it is a matter of preference (taste).

---

I was thinking specifically LSL coding and what the company's manual would say

Linden Lab has no public manual for LSL at all, so It is saying nil about style (thank God)

What compiles is valid and nobody can claim one style is superior to another

Nobody should modify a script in the wiki, compiled and published by someone else

:smileysurprised::smileyvery-happy:

[Innula Zenovka]

---

Dora Gustafson wrote:

I was thinking specifically LSL coding and what the company's manual would say

Linden Lab has no public manual for LSL at all, so It is saying

nil

about

style

(thank God

)

What compiles is valid

and

nobody

can claim

one style is superior

to another

Nobody should modify a script in the wiki,

compiled and published by someone else

:smileysurprised:

:smileyvery-happy:

---

 I'm not sure that applies to scripts in the Wiki library or to examples in the articles (though I would never take it upon myself to change one of those -- when I want to, I simply post something on the Discussion tab and let the author/Spike Strife/whoever decide).

People's own personal wiki pages are certainly off-limits, though.

 

ETA:  For clarity, I wouldn't try to change something simply for the sake of readability, though I have sometimes suggested alterations to examples and library scripts when I've thought there's a simpler or more elegant way of doing it.

[Dora Gustafson]

---

Innula Zenovka wrote:

---

Dora Gustafson wrote:

I was thinking specifically LSL coding and what the company's manual would say

Linden Lab has no public manual for LSL at all, so It is saying

nil

about

style

(thank God

)

What compiles is valid

and

nobody

can claim

one style is superior

to another

Nobody should modify a script in the wiki,

compiled and published by someone else

:smileysurprised:

:smileyvery-happy:

---

 I'm not sure that applies to scripts in the Wiki library or to examples in the articles (though I would never take it upon myself to change one of those -- when I want to, I simply post something on the Discussion tab and let the author/Spike/whoever decide).

People's own personal wiki pages are certainly off-limits, though.

---

I do not disagree. You say it better than I do

:smileysurprised::smileyvery-happy:

[Madelaine McMasters]

---

Helium Loon wrote:

Any user function calls within a block would also require a new thunk, since the return address needs to place properly in the execution stack (so things unwind properly.)  So unless the block contains NO references to local variables or global functions (in Mono/LSL, in C/C++ and other languages it gets even more complicated) then the block contents wouldn't require a thunk.  Not sure if built-in functions would also require it.....

 

Analyzing that for a large block could get quite messy.  I'd have to actually look at the Mono compiler code to see how it handles this...... Not sure if it would bother analyzing code that in-depth.  Obviously, modern high-level language compilers do a LOT of optimizing and analyzing.....but I doubt Mono does more than cursory optimization.

 

---

I'm still not sure there's any overhead for putting a simple statement inside a block by itself. If that sole statement is a function call, it'll need the same stack frame whether in a block or not. Since we're talking about bracketing simple statements, are there examples of them that would have local variables?

The compilers that I used in my embedded work (GCC derivatives) would generate the same code for a simple statement, regardless if it was in brackets or not. If allowed, they could also inline functions, unroll loops and do all sorts of things that taxed my ability to recognize my algorithm in the resulting assembly language and made it nearly impossible to trace execution with my logic analyzer, or to single step through non-existent loops with the debugger.

Mono is a bytecode interpreter and I've no idea what the virtual machine looks like, nor how the compiler handles the situation we're discussing. This seems like something a curious person with excess spare time could test ;-)

[steph Arnott]

Linden Lab has no public manual for LSL at all, so It is saying nil about style (thank God)

Second life scripting your world book clearly sets out style.

[Rolig Loon]

That's just the specific style that the authors of that book use, Steph.  There's nothing official or magic about it.  They don't represent LL either.

[steph Arnott]

OK, i just used that. Assumed it was LL, but i take your word for it.

[Helium Loon]

---

Madelaine McMasters wrote:

Mono is a bytecode interpreter and I've no idea what the virtual machine looks like, nor how the compiler handles the situation we're discussing. This seems like something a curious person with excess spare time could test ;-)

---

Sorry, no spare time here.....busy writing stuff under WinCE at work.....*ugh*.....

 

---

Madelaine McMasters wrote:

I'm still not sure there's any overhead for putting a simple statement inside a block by itself. If that sole statement is a function call, it'll need the same stack frame whether in a block or not. Since we're talking about bracketing simple statements, are there examples of them that would have local variables?

The compilers that I used in my embedded work (GCC derivatives) would generate the same code for a simple statement, regardless if it was in brackets or not. If allowed, they could also inline functions, unroll loops and do all sorts of things that taxed my ability to recognize my algorithm in the resulting assembly language and made it nearly impossible to trace execution with my logic analyzer, or to single step through non-existent loops with the debugger.

 

---

Oh, I agree about modern compilers.....said so above.  They optimize heavily these days.  But bytecode interpreters and compilers for Mono?  Not so sure about those.  And we BOTH know how lazy programmers can be.......

 

 

[Madelaine McMasters]

---

Helium Loon wrote:

Sorry, no spare time here.....busy writing stuff under WinCE at work.....*ugh*.....

Poor baby! Need a hug?

And we BOTH know how lazy programmers can be.......

   

Grrr, I'm afraid we do.

---

 

[LepreKhaun]

---

steph Arnott wrote:

OK, i just used that. Assumed it was LL, but i take your word for it.

---

There are two LSL style guides available to us, Steph, but both are user-written (I'd be surprised to hear that the Linden's cared one way or the other how we wrote our code*); https://wiki.secondlife.com/wiki/LSL_Style_Guide and a more comprehensive one at http://lslwiki.net/lslwiki/wakka.php?wakka=styleguide.

 

If you follow the guidelines set out in at least the first of those, you shouldn't run afoul of anyone's definition of style. But, then again, correct code is the only matter of importance. It doesn't matter how well named one's variables, how strictly you've indented every code block or how well you've followed your choice of case naming- if it doesn't compile, doesn't accomplish the specified task and fails to handle possible input correctly, it's "bad" code in the truest sense.

 

But even "bad" code shouldn't be corrected within a wiki User Page imo. There is a discussion/talk for every page in the wiki (accessible by tab at the top or a "Display comments/form" link at the bottom) that such errors can be pointed out to the user, leaving them to correct or ignore as they choose.

 

Of course, that doesn't apply to the main body of the wiki, the pages not within someone's name space. Even picayune details such as spelling and grammar should be corrected (with such edits flagged as "minor"). And "bad" code examples, though rare in the wiki, should be corrected as soon as they're found. It is our wiki and will be only as good we make it.

 

* A possible exception would be in writing a Jira to report a bug. A Linden could expect at least proper indentation in your example and might complain if it lacked that.

[PeterCanessa Oh]

@ All, not LepreKhaun: Please feel free to tell me off if you disagree but I thought style never goes out of, er, style so I'm bumping this thread because I thought you'd like this:

I am currently reading "Making Games With Python And Pygame" by Al Sweigart.  It is intended for beginners with some programming experience (he also wrote "Invent Your Own Computer Games with Python" for complete novices).  Amongst the example code he has this to say at the end of Chapter 3:

 

Why Bother With Readability?A lot of the suggestions in this chapter haven’t been about how to write programs that computers can
run so much as how to write programs that programmers can read. You might not understand why this
is important.  After all, as long as the code works, who cares if it is hard or easy for human
programmers to read?
However, the important thing to realize about software is that it is rarely ever left alone. When you
are creating your own games, you will rarely be 'done' with the program. You will always get new ideas
for game features you want add, or find new bugs with the program. Because of this, it is important
that your program is readable so that you can look at the code and understand it. And understanding
the code is the first step to changing it to add more code or fix bugs.
As an example, here is an obfuscated version of the Memory Puzzle program that was made entirely
unreadable. If you type it in (or download it from http://invpy.com/memorypuzzle_obfuscated.py)
and run it you will find it runs exactly the same as the code at the beginning of this chapter. But if
there was a bug with this code, it would be impossible to read the code and understand what’s
going on, much less fix the bug.The computer doesn’t mind code as unreadable as this. It’s all the same to it....Never write code like this. If you program like this while facing the mirror in a bathroom with the
lights turned off, the ghost of Ada Lovelace will come out of the mirror and throw you into the
jaws of a Jacquard loom....In fact, if you’d like some practice fixing bugs, there are several versions of this game’s source
code that have small bugs in them. You can download these buggy versions from
http://invpy.com/buggy/memorypuzzle. Try running the program to figure out what the bug is,
and why the program is acting that way.

 

In other words, readability is not just about LSL, it's about all programming languages that allow it.  (And if you don't know who Ada Lovelace was go and look her up! (and Grace Hopper (all praise her)))

 

[Madelaine McMasters]

---

PeterCanessa Oh wrote:

Grace Hopper (all praise her) 

---

I do, every time I pull a nanosecond out of my purse!  I also have a microsecond on a small spool, and I'm thinking of purchasing a millisecond, or at least half a millisecond.

Grace rocks!...

[PeterCanessa Oh]

I've never really understood why that was her trademark, to be honest.  I met her once but she wasn't handing them out then.

[steph Arnott]

Because there two types of history. One made up by stupid people or clever propagandists and real history. Some of the most respected people in history were not as great or even very nice  that a lot of people would believe.Florence Nightingale, solders had more chance of surviving in a battle field hospital than hers.

[Perrie Juran]

---

steph Arnott wrote:

Because there two types of history. One made up by stupid people or clever propagandists and real history. Some of the most respected people in history were not as great or even very nice  that a lot of people would believe.

Florence Nightingale, solders had more chance of surviving in a battle field hospital than hers.

---

The same is true about Mother Teresa.

[Rolig Loon]

So idols have clay feet.  Is this news?

[Madelaine McMasters]

---

Rolig Loon wrote:

So idols have clay feet.  Is this news?

---

That's an improvement over our feet of wood, Rolig.

[Perrie Juran]

---

Rolig Loon wrote:

So idols have clay feet.  Is this news?

---

nope

[steph Arnott]

LOL.