Gradually I understand less and less the meaning of the keyword then in if then statements. And I often forget to type it, since I doesn’t feel logic anymore.
If a = 5 Then
…
End if
Why not
If a = 5
…
End if
5 Likes
+1 
1 Like
Did you know you could hit shift-return after the condition and it will fill in the rest for you?
1 Like
There’s
If a > 1 Then b = c * a // one-liner case
The “Then” marks the end of the evaluation and the start of the execution
What about Select Case ?
Just semantically better to read
Select Case testExpression
[Case [Is] expression-n [statements-n]
Else or Case Else
elseStatements]
End [Select]
Yes Kem, I know and use that shortcut, but it’s simply not in my nature anymore to add a THEN. Sometimes I accidently type a { instead. 
2 Likes
I know, but there is simply no need for it if you continue on next line
3 Likes
If we compare “If … Then” to other programming languages, for example PHP, you can clearly see that we need it.
For example:
if(x > 5)
{
}
In this case the closing bracket “)” marks the end of the condition. That’s why we need “Then” in Xojo language.
“Then” is useful for one-liners, for example: If x > 5 Then App.execute(blah) End If”
Sometimes you want to use short one-liners.
Not necessarily. Many languages can omit these open and close tokens, and it’s all in how the language is designed. Take JavaScript, for example, which uses semicolon as the line token. You can do a one-line if:
if (a > b) return "a is greater";
Or do the same in two lines:
if (a > b)
return "a is greater";
Or with the traditional curly brace tokens:
if (a > b) {
return "a is greater";
}
It’s certainly feasible that Xojo could add EOL as a token in these scenarios, I’m just not sure the gain is worth the trouble. I, personally, catch myself leaving off the “Then” on conditional statements from time-to-time as I work in other languages quite a bit, but I don’t think removing the “Then” requirement is a solution any more than I want to see curly braces and semicolons in Xojo code.
Yes that is because you have the closing bracket! → “)”
If you wouldn’t have the closing bracket, the code wouldn’t work. It would throw an error.
2 Likes
Style and options.
I do prefer to write a terse:
If theWindow.NeedsLayoutWorkarounds() Then theWindow.FixTheLayout()
Than a 3 lines:
If theWindow.NeedsLayoutWorkarounds() // Then
theWindow.FixTheLayout()
End If
2 Likes
Again, it’s all about language design choices. The open curly brace is a direct relation to Then with the close curly brace equating to the End If, despite the conditions being encapsulated in parens.
At any rate, I’m getting us off-topic. I prefer Then be a requirement for readability if nothing else.
2 Likes
I agree with this. I like a good one-line If.
1 Like
But we both agree that it is absolutely necessary to have a character or coherent characters to indicate the end of a condition. As for example: Then or “)”.
I tried to make that clear.
1 Like
Yes, we can agree on that. Whether it be a close parenthesis, close curly brace, or EOL. There has to be something for the tokenizer to see as the break point in the code block/line.
1 Like
Playing devil’s advocate, why can’t the EOL be that marker?
(And even though I run into the same inconvenience with “Then”, I don’t advocate changing it.)
It could, but you’d still need Then (or some other token) for single-line Ifs and why create a confusing difference?
The great thing about standards is there are so many to choose from!
2 Likes
Making it optional for a traditional IF would not create confusion, IMO, just as the optional keyword after “End” does not create confusion. It would affect backwards compatibility though, but there are already features that do that.
Note that “Then” is already optional for #If, and that, if anything, is confusing, i.e., why is it optional there but required for the traditional If?
(If anything, I would have preferred that the keyword after End be required, but that ship has long sailed.)
1 Like