While Loop bug?

My understanding of While loops is that they won't run the code block if the condition is false (i.e. test condition first, then run code block if true)

But the do...while loop will always run the code block at least once (i.e, run code, then test)

So why does this code not work correctly?

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

touch_start(integer total_number)
{

integer intLowerValue = 4;
integer intHigherValue = 10;

while(intLowerValue > intHigherValue);
{
llOwnerSay("Why did this loop run? Condition is false";

}
}
}

Am I missing something or is http://wiki.secondlife.com/wiki/While incorrect?

while(intLowerValue > intHigherValue);
(intLowerValue > intHigherValue);
intHigherValue);
;

/me takes peoples semicolons away!

edit: any time you see a line of code followed by some {}'s, that first line of code probably should not have a ; at the end of it..

Try:
while(intLowerValue > intHigherValue)
{
llOwnerSay("Why did this loop run? Condition is false";
}

What your code is saying is actually something like:

while(intLowerValue > intHigherValue)
{
}

llOwnerSay("Why did this loop run? Condition is false";

1TBS FTW.

Uggg, I was pulling my hair out trying to figure out why the code didn't work. Stupid semi-colons.

Thanks for showing me the light

Part of the learning curve and it has bitten most of us at one point or another. The other one to hurry up and get out of your system is this one:

if( something = something)

instead of:

if(something == something)

a tablespoon of what?

seriously what is 1tbs in this context? LTBS leetified? If so, what is LTBS?

"The One True Brace Style" aka K&R

It's a habit for me when comparing variables against values to have the value in the left hand position and the variable in the right (5 == fun); that way if I typo on the ==, I get a compiler error.

Yep.. It's a code formatting style that puts opening { at a different indentation level than their partner }.

Since if makes it harder to see the structure of the code, it's useful for when your boss is always looking over your shoulder, trying to decide if you make too much money. Never let management be able to read your code or they'll begin to think they can write it, too!!

hmm really? compare an extended "if else if else if else if else if else" in both code styles and tell me that avoiding cuddled braces is more readable... or that cuddled braces don't in fact clarify control flow (as well as avoid the ; problem).

Next up - spaces or tabs

Tabs!!!

They make stuff compile faster than spaces do.

Tabs of course, spaces get fucked up too easily.

while (something) {
...
}

Instead of:

while(something)
{
...
}

It makes it REAL clear that you've got surplus semicolons; {

And, no, it doesn't make code hard to read. Indentation matters.
In LSL? "The tab is a lie!"

Tweaked and customized an indent program as a plugin for Scite to output using K & R. This coupled with Strife's whitespace stripper to get rid of 50 lines of comments makes reading and debugging posted code much more pleasant. The biggest advantage of K&R to me is the fact that you are able to "compress" the code with the same readability.

Hey let's all report Strife!!!!!!

(kidding! Love you as always Strife and miss your Moderating awesomeness)

lol, the good old days.

The irony is, we didn't care if people cursed as long as it wasn't directed at people...

I've been trying to cut down on my cursing though, but sometimes I slip up and say "Fuck" then I realize my mistake and say "shit"...

But really, bad whitespacing is something to curse about. It makes code hard to read and unless you have a tool to clean it up for you... it takes a bunch of time to get it fixed. Not mentioning that it makes maintaining the script harder for the author. Seriously, it's just better to do it right the first time; saves everyone time and effort.

Don't get me wrong, while I prefer tabs/4 spaces, I'll take what ever I can get as long as it's consistent.

IMHO indentation should be all the visible cue you need for structure

if (X){
}

produces lower chanses of having an extra semicolon, but higher chance to forget the opening brace

if (X)
{
}

produces the exact opposite likleyhoods

if you find yourself checking for semicolons more often than braces you'll prefer the first

if you dislike extra white space, same applies.

as for bosses looking over your shoulder, condensed code looks more complex, like they're getting more work out of you, but whitespace can make it look larger, and can hide large portions off screen if you're in one of those back stabbing labs...

I prefer the former personally

... I never considered the office politics issues of coding style. Well, except for one thing...

One place we were working on the internal C coding standard, and there were people who were strongly for and against each of these styles. I came up with weasel words that managed to convince both sides they'd won long enough to get it signed off.

I just happen to prefer that opening braces are indented with more than just one space on at the end of the previous line..


True - picking a style and sticking with it is half+ the battle..

100% agree with this.

The other half is about maintainability. I'm going to detail *why* I think cuddled braces are superior.

Ironically, for smaller scripts I think the more extended brace style is actually easier to "grok", but only for smaller scripts.

As the code length increases and the overall structure of the script gets more complex, unnecessarily extended code blocks increasingly obfuscate the overall structure and intention of the design.

If you directly compare 800-1000 line scripts (which is about as big as we are "allowed" in each brace style and I think you'll appreciate why I say this.

My 5c
/esc

Here on my home machine, I get about 60 lines of code on the screen at once. At work, where I don't have to buy the monitor myself, it's probably closer to 75. Back when K&R was written, late '70s, they probably had 24 line terminals. Or maybe even working on those horrible teletype paper things.

/me wonders what the K&R coding style would look like if they had big honkin' LCDs with no real worries about screen real estate back then...

....hmmm.... perhaps I should have said "if you directly compare 800-1000 line scripts *that you did not write yourself*. The same consideration applies but it's even more obvious!

/esc

BTW I surely don't think that this is a "winnable" argument, or even that "I know for sure". I'm just stating the evidence as I see it

so... an example... check out these two touch_start events :

http://pastebin.com/m2a237228

To my view, the first overemphasizes the keywords, the second provides a balanced emphasis of the actual actions, and it's easier to see where the control flow blocks begin and end.

In the first, the white space immediately disconnects me between the declaration and the reason the event/flow block is called. This "semantic break" increases for me as the complexity of the code increases. The following is what the white space does "in my head" when reading the first...

if (test) NEW BLOCK do_this END else NEW BLOCK do_something_else END

...and the second...

if (test), do_this, else, do_something_else END

...maybe it depends on how your personal head works

true but odd, I actually learned most of my style raw, not from comparing differing styles, and not from the text book style which tended to seperate all braces (although true be told, mine was a compromise in some places, when writing jscript I had the habit of stacking ending braces).... I also disliked the convention of writing all function variables at the begining... I prefer them before the section I'm working with them, saves me from having do nothing varibles on edits, and allows me to throw them in for structures as I'm writing (sorry, I don't that level of preplanning, stick your flow chart elswhere)

the thing it comes down to for single programmers is confort and ease of use... if you are used to writing a certain way, and doing that makes it easier for you to work with, I say go for it.... when you work with others though you'd better be prepared to compromise, so it never hurts to use a style that if not easy for others to write, is easy enough for them to follow. and if you do it for someone else, you'd better believe the person signing the checks gets to dictate stupid things like style and comment formatting if they read it.