Is it me, or are if statements messy?
-
ifstatements look a bit messy to me. In a more familiar programming language style, multipleifconditions would look like this.if (abc == 123) { // Do these // statements } else if (abc == 321) { // Do these // statements instead } else { // Forget it, just // do these statements }In Fuze, it looks more like this
if abc == 123 then // Do these // statements else if abc == 321 // Do these // statements instead else // Forget it, just // do these statements endif endifLooking at these side-by-side, the main problem is that the
endifencloses theelse.I feel the
elseshould be allowed to appear on the outside immediately following anendif. Making it look more like thisif abc == 123 then // Do these // statements endif else if abc == 321 // Do these // statements instead endif else // Forget it, just // do these statements endif -
Is it a case of using an indenting style that makes the nesting clear?....
if abc == 123 then // Do these // statements else if abc == 321 then // Do these // statements instead else // Forget it, just // do these statements endif endif -
Well, ignoring that one is syntactically correct for Fuze and the other not, it's just down to personal taste how you lay them out.
I think mine tend to look perfectly nice enough. Not the same as in Java which is my usual language, but I accept that as fine because this simply isn't java.
For me, I don't see anything wrong with either of these. Note, I add brackets simply because if I don't then when I go back to my Java IDE it moans at me a lot. They are not required in Fuze as we know...
if (line == single) then noNewLines = fine endif if (abc == 123) then // Blah else if (code == 456) then // Blah endif endifOh, just to add - I'd qualify the "single line is fine" with "as long as it isn't too long". How long is too long? No more than a screen width but in old terms, probably around 100 to 120 characters. But again, no hard rules here.
-
@Martin Probably just need to wait for Fuze to add switch cases. The way we're nesting the
ifstatements will be a heachache when we start to add a multitude of them, with each one being more indented. This is why I opted not to indent mine. I just have to deal with multipleendifstatments being stacked for eachelse if*shudder *
if (abc == 111) then // blah // blah else if (abc == 222) // blah // blah else if (abc == 333) // blah // blah else if (abc == 444) // blah // blah else if (abc == 555) // blah // blah else //blah //blah endif endif endif endif endifcompared to
if (abc == 111) then // blah // blah else if (abc == 222) // blah // blah else if (abc == 333) // blah // blah else if (abc == 444) // blah // blah else if (abc == 555) // blah // blah else //blah //blah endif endif endif endif endif -
@_JKDOS FWIW, there's no need for using "else" in the example, since none of these are in conflict (unless "abc" is changed within the "if" block). But if you want it structured like a case statement, you can do:
while true loop if (abc == 111) then // blah // blah break endif if (abc == 222) then // blah // blah break endif if (abc == 333) then // blah // blah break endif if (abc == 444) then // blah // blah break endif if (abc == 555) then // blah // blah break endif break repeat -
I agree it is a bit of a mess, it would be nice if they just gave us an elseif instead of having to nest subsequent cases inside of our else.
-
If you feel strongly about this please add something to the Wishlist post https://fuzearena.com/forum/topic/11/wishlist/168
Personally I would like to have a switch/case statement
-
An elseif keyphrase (or elif) could simplify the process as well
-
I like it the way it is.... but if you added an elseif would you still need an additional endif? and would it break the original coding, because, that would be a boring day of editing broken code...
-
My preference with IF statements is is more like:
if ( a >5 ) then bDone = 0 else bDone = a endifI like less lines hahaha
-
The point of an elseif keyword is that it would be used in a statement such as if condition then statement elseif condition 2 statement elseif condition 3 statement endif. That would make it one long statement that doesn't need pairing off for each condition. That means nested statements aren't necessary as often. That's the way lua and some versions of basic do it. I'd like to see it in FUZE, but it's not necessary, just helpful. In C like languages like Java and Javascript you don't need another syntax for it because a single statement doesn't need an extra set of braces, so you can use the two separate words else if and it will still balance out and be a valid statement.
-
I can't see IF statements changing but we will be adding SWITCH for sure.
-
@Jonboy Switches in my Switch? Switchception!
-
Just wait till the XBOX version!
-
-
@Nisse5 said in Is it me, or are if statements messy?:
@_JKDOS FWIW, there's no need for using "else" in the example, since none of these are in conflict (unless "abc" is changed within the "if" block). But if you want it structured like a case statement, you can do:
That is really neat.
-
I also feel like
ifstatements have room for improvement. I've expressed some ideas below. Even though it might not 100% align with the ideas of the Fuze team, I hope my chain of thought is useful anyway:inline if statements
IIF
If the arguments to a function call are conditional, I currently do not have many options. Basically I see two patterns:pattern 1:
value = 1 if condition then value = 2 endif stuff(value)pattern 2:
if condition then stuff(2) else stuff(1) endifI would however like to use the inline if statement pattern (from other languages:
stuff(condition ? 2 : 1)).
In F4NS I'd think a syntax like this would work:stuff(IIF condition THEN 2 ELSE 1 ENDIIF)IIFstanding for 'inline if', and ending withENDIIFin stead ofENDIF.Fundamentally the difference is that an
IIFmust always decide on a statement that returns a value. Opposed toIFthat executes conditionally.keyword to prevent nesting
ELSEIFELSEIFcould easily be a keyword, that helps reduce the amount of nesting for correlated if statements (keeping the cognitive load of the code lower). This way only oneENDIFkeyword would be needed for correlated conditions. It would be possible to follow upIFwith multipleELSEIF's and even one optionalELSEafter those (ELSEIFwould not be possible afterELSE).For example:
string value IF i < 0 THEN value = "negative" ELSEIF i > 0 THEN value = "positive" ELSE value = "neutral" ENDIF // using ELSEIF would not require an additional endif stuff(value)combining the two keywords
The following code could be reduced if we were allowed to combine those two keywords. Currently in F4NS you would write something like this:string value if i < 0 then value = "negative" else if i > 0 then value = "positive" else value = "neutral" endif endif stuff(value)A possible option would be to introduce
ELSEIIF(as an inlineELSEIF):stuff( IIF i < 0 THEN "negative" ELSEIIF i > 0 THEN "positive" ELSE "neutral" ENDIIF)Or otherwise IIF could be nested like so:
stuff( IIF i < 0 THEN "negative" ELSE IIF i > 0 THEN "positive" ELSE "neutral" ENDIIF ENDIIF )Type agnostic short circuiting
I guess you could name the following pattern "type agnostic short circuiting". It can be addictive, and this would work in JavaScript, but for F4NS this would probably be a bad idea:
stuff( (i < 0 && "negative") || ( i > 0 && "positive") || "neutral")I know F4NS has the
ANDandORkeyword, but in my opinion it's more intuitive if those keywords would always resolve in a boolean value, where as&&and||would then be able to resolve to other types (as shown in the example above).
