Is it me, or are if statements messy?

Aceba1

An elseif keyphrase (or elif) could simplify the process as well

Alexander

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...

Jongjungbu

My preference with IF statements is is more like:

if ( a >5 ) then bDone = 0 else bDone = a endif

I like less lines hahaha

Hitomi

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.

Jonboy

I can't see IF statements changing but we will be adding SWITCH for sure.

Discostew

@Jonboy Switches in my Switch? Switchception!

Jonboy

Just wait till the XBOX version!

Discostew

@Jonboy said in Is it me, or are if statements messy?:

Just wait till the XBOX version!

Wait, wha?

_JKDOS

@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.

PB____

I also feel like if statements 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)
   endif

I 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)

IIF standing for 'inline if', and ending with ENDIIF in stead of ENDIF.

Fundamentally the difference is that an IIF must always decide on a statement that returns a value. Opposed to IF that executes conditionally.

keyword to prevent nesting ELSEIF

ELSEIF could 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 one ENDIF keyword would be needed for correlated conditions. It would be possible to follow up IF with multiple ELSEIF's and even one optional ELSE after those (ELSEIF would not be possible after ELSE).

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 inline ELSEIF):

   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 AND and OR keyword, 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).