Jump to content

if and else if


steph Arnott
 Share

You are about to reply to a thread that has been inactive for 4085 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

"else if" is fine, no need to fully evaluate all those later "if" expressions in the chain that way.

Until about 5 years ago, the LSL compiler would choke on fairly short "else if" chains if you were compiling under Windows, and "if ... if ..." was the workaround. This problem went away when all compiling moved to the server.

  • Like 1
Link to comment
Share on other sites

It's fair to say which you use depends on the flow you need. I don't know how LSL compiler worked 5 years ago, but this works now the way it does in other languages in all cases I've seen; each has its purpose.

if - can work by itself without any else or else if following it. If the condition is not met, the block is just not entered, but the condition is always evaluated for true or false. Using ifs when and else or else if is appropriate means the script will always evaluate the condition for true or false - even if it does not need to.

else - an ultimatum. If used, it must directly follow either an if or else if. If the if or else if(s) it follows had a condition that evaluated as true, all blocks that follow, including this one, will be skipped over. If none of the previous conditions were true, this will ALWAYS be entered. Using it depends on if you absolutely have to have something happen if the conditions before it were not met. If nothing has to happen when the earlier conditions are false, this does not need to exist. If this is used, it is always the 'end of the line' - a required alternative after an if or ending a series of else ifs.

else if - beneficial to prevent scripts from reading through multiple conditions when it does not need to. Its condition is never evaluated (skipped over) when an if or else if directly before it was true. When this one is true, the script skips over any else ifs or else that follows, not needing even to read the condition.

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

(You know this, Steph, but others may not)

The difference between if .. else if .. else if ...  and a simple chain of if... if... if   is that  "if.. else if...else if.. "  continues to evaluate until it finds a condition that is true, and then stops, ignoring anything later on.    If.. if.. if, in contrast, evaluates all the conditions.

So, if only one condition out of several is going to be true, then if.. else if.. else if.. is best.   However, if you want to evaluate several conditions and know that more of them might be true, then if.. if.. if is the way to do it.

  • Like 2
  • Thanks 1
Link to comment
Share on other sites

"else if" can save a lot of processing because the computer doesn't need to evaluate a lot of already-known tests.

 

Something = "Option 2";//=======================================================if("Option 1" == Something){	// The computer checks to see if it is	DoThing(1);}if("Option 2" == Something){	// Then checks this	DoThing(2);}if("Option 3" == Something){	// Then this	DoThing(3);}...if("Option 2199999999" == Something){ // And has to check all 'if' tests	DoThing(4);}//=======================================================if("Option 1" == Something){	// The computer checks to see if it is	DoThing(1);}else if("Option 2" == Something){	// Then checks this, because it wasn't "Option 1"	DoThing(2);}else if("Option 3" == Something){	// But skips over this, because it has already found a test that works	DoThing(3);}...else if("Option 2199999999" == Something){ // And doesn't have to check any other 'ELSE' tests either	DoThing(4);}

 

Geek post #3:
=============

Note that there is no separate "else if" statement - it's an "else" immediately followed by an "if" and, to be totally consistent, should have its own set of braces,

Technically "else" is a statement which executes the following single statement IF the previously-executed "if" statement failed (evaluated to false). The formatting should, strictly, therefore be:

 

if(test1)	...else	if(test2)	// <== 'if' is the single statement being executed		...

 

Braces ("{" and "}") are used to 'wrap' several statements into a single statement - a "code block" - and, for various reasons we have been discussing recently, many (most?) people insist on braces even around single statements, "just in case", so it becomes:

 

if(test1){	...}else{	if(test2)	{		...	}}

 

So the 'proper' formatting for a chain of 'else ifs' calls for more and more indentation and braces, but I don't know anyone who thinks that's easier to read or debug! In my opinion:

 

if(test1){	...}else if(test2){	...}else if(test3){	...}else{	...}

 

is a much 'nicer' form than:

 

if(test1){	...}else{	if(test2){		...	}	else{		if(test3){			...		}		else{			...		}	}}

 

:matte-motes-wink: The difference between several IFs and a chain of ELSE IFs is a matter of logic and processing.  None of the formatting makes the slightest difference to the compiler it's just coding-style for humans.

 

Link to comment
Share on other sites


PeterCanessa Oh wrote:

[ ... a lot of interesting and useful stuff, followed by ....]

So the 'proper' formatting for a chain of 'else ifs' calls for more and more indentation and braces,
but I don't know anyone who thinks that's easier to read or debug!
In my opinion:

 
if(test1){	...}else if(test2){	...}else if(test3){	...}else{	...}

 

is a much 'nicer' form than:

 
if(test1){	...}else{	if(test2){		...	}	else{		if(test3){			...		}		else{			...		}	}}

 

:matte-motes-wink: The difference between several IFs and a chain of ELSE IFs is a matter of logic and processing.  None of the formatting makes the slightest difference to the compiler it's just coding-style for humans.

 

Ah, well ..... I do.  But that's one of the many places where coding style for humans really relies on the human's frame of mind.  To my mind, it's easier to see blocks of "do this stuff first andf that stuff next" if the code blocks are prioritized visually by indenting them.  When I face a cloud of nested if - else if conditions that haven't been indented, I have to get out my mental red pencil and indent them myself to be sure that I don't miss something vital.  I think it has something to do with having chosen life as a chemist instead of a computer scientist. (Every experiment in its own beaker.)

  • Thanks 1
Link to comment
Share on other sites

Interesting - I'd never noticed that in your coding style.  The reason I prefer the first form in the section you quote is that it makes it easy - for me! - to see that "test1", "test2", etc. are related alternatives, whereas in the second form I find it harder to connect "test3" with "test1", Where "test3" is checking something different though I'd definitely use indentation and braces, like you - precisely to make that difference distinct.

Anyway ... I ramble ...it does come down to personal or house style.

 

Link to comment
Share on other sites

I just indent as the SL book told me. Everyone here has confirmed my original understanding, but and this is the reason I asked the question is that I had to learn my self so when a person who programs as a professional I think well they know and I just an amateur as result of the post I now have the confidence to stand my ground, thanks all.

Edited: sorry my english spelling i not good, LOL

Link to comment
Share on other sites


Rolig Loon wrote:

Ooop. I was looking precisely at the case of nested conditions when I wrote my indentation comment.  I misunderstood your post as a general argument against indenting.  "
Never mind, then
," as Gilda Radner used to say. 

That's the trouble with my over-geeked rambling complicating the issue :-) The main point I was trying to make was that "else if" is actually two statements in LSL but it's usual to treat them as one because it's easier to read.

In LSL they are an "else" followed by an "if", not a distinct third "elseif" statement that some other languages have - see "elif" in python, for instance.

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 4085 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...