I also believe that denoting the variable or block name after End
should not be optional, and that Then
should be required for conditional compilation.
Yeah, I never remember to do that either.
And what about this:
Return If(Rs.Column("integrity_check").StringValue = "ok", True, False)
That’s a different sort of if
(name escapes me at the moment). In PHP etc that looks like:
return somevar==22 ? True : False;
which is better syntax IMO.
Meanwhile, I’ve always hated that syntax because the condition comes first without any indication of purpose until you read the entire line.
Oh Kem, really! You can’t stack it until the punctuation marker? Don’t try reading German, then, need a deep stack for that!
Funny to see how everybody may have his own codingstyle. It often not that one is definitely better than the other. I do often use the oneliner as above, to me it’s fast and logical, and often I also do replace the True and False by different complex functions.
There is one thing against oneliners, I believe. It’s not most handy while debugging.
Another one:
If iPs = iOk Then
Return True
Else
Return False
End If
This looks to me as poor coding.
I would code:
Return (iPs = iOk)
This is the same as the usual
Return ( Rs.Column("integrity_check").StringValue = "ok" )
Inline IFs are more useful when transforming results like:
Return If( found, 200, 404 )
keep in mind that source code change daily.
i like readability more than optimisation.
for debugging it is better to have a variable before the output or a break point as example at the true condition.
Xojo could support 2 spellings.
If .. Then .. Else .. End If
and
If (..) {..} Else {..}
I doubt using punctuation as delimiters will ever happen, and I’d be against that anyway, FWIW.
I don’t think Xojo should do away with “Then”, but I do wish the IDE would simply add it instead of throwing an error when checking or compiling the project. I can’t imagine a situation where I would need to know that I forgot to type it as opposed to it being filled in for me.
„Then“ is syntactic sugar; an if-statement expects an expression that evaluates to true or false. Nothing more (except more boolean evaluations that are „or“ed and/or „and“ed). Thats all, no need for „then“ or something similar. You need brackets only if there is more than one statement to be executet.
BTW: Not every BASIC dialect uses „then“.
Whatever you do, don’t do this:
#If XXX Then YYY Else ZZZ
It will lead to very strange errors elsewhere in your app! Spread it over multiple lines ending with #EndIf.
Mr Belling, I think that you don’t understand what I’m saying, more specifically I think that you don’t understand why it would be mandatory to have a character to mark the end of an expression.
Every programming language I know of has got a character to mark the end of an expression!
Anthony G. Cyphers explained it very well:
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.
Python:
if x != y:
→ :
Apple Swift or C++ or PHP:
if (x != y)
→ )
Xojo Basic:
If x <> y Then
→ Then
I’m not trying to be rude or something, but I’m not going to discuss this more with you.
More code examples here: http://marmaro.de/docs/studium/syntax-vergleich/syn.pdf
Syntax is not part of the tokenizer. For the syntax analyzer it’s not hard to recognize expressions and statements w/o braces or special keywords like “Then”.
For example:
if <expression> <statement> --> if i < 100 i = i + 1
You need brackets to tell the compiler that more than one statement is part of the execution tree:
if <expression> { <statement 1> <statement 2> ... }
This has nothing to do how this is implemented in other languages.
Before I put {
to Then
and }
to End If
into my reformat code script, does Xojo use { } for anything?
No. Not square brackets either.
Thanks Kem, something for me to do tomorrow
Another option is:
Return (Rs.Column("integrity_check").StringValue = "ok")
if the return value expected is a boolean
edit: i see rick has suggested the same already
I want whitespace added. You don’t how how really great handling of whitespace at the beginning of a line is when you have to handle that yourself. That alone makes Python so utterly terrible.