Scripting an AND conditional...Single Line "If" or Nested "If"s?

Lounge (Discussions)
1

Which method for scripting an AND conditional do you prefer?

  • Single "If"
  • Nested "If"s

Does the Single "If" method "short circuit" (a good thing in this context)?

image

2

The first is more compact, but I often prefer the second as I have two lines for debugger to stop to see the result of each IF check.
And I can use two ELSE for handling other cases.

5 Likes
4

Good points.

image

5

I love guard clauses. They are clear and concise.

If [ not CF_gui_client ]
    exit script
End If
# go ahead, we have GUI client

Much more readable and easier to maintain than the alternative

If [ CF_gui_client ]
    ...
    ... hundreds of lines of code ...
    ... many IF clauses
    ...
End If <<-- who does this belong to?
6 Likes
6

It depends. If the second clause has a single condition, a single ‘If’ line is fine and produces readable code. If the second clause has multiple conditions to check ‘Else If’, the nested version is easier to read.

7

Guard clauses can create problems. For example:

# Initialization.
Go to Layout [ "Some Layout" (Some Table) ; Animation: None ]
... other initialization code ...

# Guard clause
If [ some if condition ]
    Exit Script [ some exit condition ]
End If

... more code ...

# Cleanup.
Go to Layout [ original layout ; Animation: None ]
... other cleanup code ...

I use what I call error-based code execution when warranted. For example:

# Initialization.
Set Variable [ $error ; 0 // No error ]
Go to Layout [ "Some Layout" (Some Table) ; Animation: None ]
... other initialization code ...

# Validation.
If [ some if condition is not met ]
    Set Variable [ $error ; -1 // Or any other error code ]
End If

# Code block 1.
If [ not $error ]
    ... some code ...
    ... which may set the $error value ...
End If

# Code block 2.
If [ not $error ]
    ... same idea as code block 1 ...
End If

... more code blocks ...

# Cleanup.
Go to Layout [ original layout ; Animation: None ]
... other non conditional cleanup code ...
If [ $error ]
    ... conditional cleanup code ...
End If

# Return.
Exit Script [ some exit condition ]

I find it readable and easy to debug. Admittedly wordy.

Hope this helps.

2 Likes
8

@bdbd Anything specific that would make you prefer the pattern you describe over a single pass loop?

1 Like
9

I am a fan exit loop if especially running transactions

// RUN
Loop  	
 

   … do something
  Set Variable [ $error ; 
    Value: JSONSetElement ( "" ; 	
    ["code" ; Get (LastError) ; JSONNumber] ;
    ["message" ; "error" ; JSONString] )
  ] 
  Exit Loop If [ JSONGetElement ( $error ; "code" ) > 0 ] 


  … do something again
  Set Variable [ $error …
  Exit Loop If [ JSONGetElement ( $error ; "code" ) > 0 ] 


  Exit Loop If [ True ]  //terminate loop
End Loop




// REUSLT
If [ JSONGetElement ( $error ; "code" ) > 0 ] 
	
	Revert Record/Request [ With dialog: Off ]
	Set Variable [ $result ; Value: $error ] 

Else

Set Variable [ $result ; 
	Value: JSONSetElement ( "" ; 	
	["error.code" ; 0 ; JSONNumber] ;
	["error.message" ; "success" ; JSONString];
	["data" ; $data ; JSONObject] )
] 

End If


Exit Script [ Text Result: $result ]
5 Likes
10

Yes, I have become a big fan of the "Single pass loop" method of constructing a script, with exit clauses that set variables like $ErrorCode, $ErrorDescription, etc. And of course, have cleanup steps at the end, outside the master loop.

But I think the original post was more a question of logical branching. That would still exist inside the overall single pass loop.

As with all things "it depends" but if the 2 conditions to evaluate are really simple (or already exist in variables for another reason), I would do that If in 1 line. If the 2 conditions are complicated and yet to be evaluated, I'll test the easier one (or the one more likely to fail the IF test), therefore short-circuiting the need for the need for second evaluation.

3 Likes
11

Was forgetting to answer…

I am no fan of single pass loops. I understand that they emulate object-oriented programming's (OOP) try (and similar) clause. While they make sense in OOP, the low-level programmer in me is not fond of spaghetti branching… which is essentially what an exit loop if statement does.

I'm pretty certain I am just being stubborn. That said, I prefer error-based code execution… more wordy, easy to follow and it handles more than just exclusion clauses.

Hope this helps.

1 Like
12

Been really appreciating seeing others' thoughts on this. Wasn't originally going to weigh in because I felt it might just repeat already posted content, but here it goes:

  • I don't much care for the nested Ifs, but there are cases (as mentioned by @flybynight), where I might sometimes use something similar to defer evaluating a potentially costly operation.

  • Though I often use compound conditions within a single IF, I have usually already evaluated the expressions in preceding lines, so that the IF statements can be comprised of variables that lend themselves to what I personally find readable.

As an example:

If( $_login_is_current AND $_operation_is_valid )

is an example of how I like my IF conditions to read.

That said -- I don't draw an absolute line on this aesthetic. If the calculation happens to be easily grokable on its own, I do not insist on first setting it to a variable. This is, of course a judgement call.

4 Likes