IF THEN

[Crivens]

I guess this can be argued either way, but in a lot of basic languages I've used in the past then any commands after the THEN of a single line IF are part of the IF. So if you look at this code:-

Code (glbasic) Select Expand

LOCAL a
a=0
IF a=1
PRINT "1",0,0
PRINT "2",0,10
PRINT "3",0,20
ENDIF

IF a=1 THEN PRINT "1",40,0;PRINT "2",40,10;PRINT "3",40,20

SHOWSCREEN
KEYWAIT
So only 2 and 3 are shown from the IF THEN line. Which is the same as saying:-

Code (glbasic) Select Expand

IF a=1 THEN PRINT "1",40,0
PRINT "2",40,10
PRINT "3",40,20
But from what I've used in the past it shouldn't be. Basically nothing should show as anything on the same line as the IF THEN are part of the single IF statement. Basically ENDIF should be implied at the line feed and not at the end of the first command (ie. the semicolon).

Cheers

[MrTAToad]

Dont forget that ; is only used to separate commands and not denote the end of a line.

Its more a case of poor code layout then an error

[Gary]

speaking personally I would find the IF ..THEN ...;...;...;...; a nightmare to debug should something has gone wrong. IF..THEN is basically a redundant command and I do find myself doing things like

IF a=1
  PRINT a,0,0
ENDIF

as its much easier to spot the start and end especially if you have nested IF statements.

And of course should I wish to add another command into the IF loop its just a case of a new line and add it in there. Much easier to read IMO

[Crivens]

I totally agree with you, and something we used to get failed in technical QA (coding standards) where I work (back when the company had a QA department).

However when it comes to keeping code size down and plonking, for example, some simple debugging on a single line (and then ignoring it forever more), then it does come in handy. I had done something similar in my code and took a bit of time tracking down exactly why it wasn't doing what I thought it was doing.

Dont forget that ; is only used to separate commands and not denote the end of a line

That's my point. An IF THEN line shouldn't effectively do an ENDIF until it hits an end of line, not a command separator (ie ; ).

Cheers

[MrTAToad]

Don't forget it follows C scoping rules whereby only the next command is part of the if statement if no curly brackets are used - which they arent 

[Crivens]

True. But it isn't C and is supposed to be a version of Basic. That's the beauty of it really and has been for years when you haven't got time anymore to learn C, and chuck something out in record breaking time (ah the good old STOS/AMOS days bring a tear to my eye). Sure it's nice to be able to embed C routines into the code to enhance it's functionality, but the core syntax is Basic.

I've used a lot of Basics over the years and to keep it consistent would require the automatic ENDIF on an IF THEN line at the end of line character (not end of command character).

Cheers

[MrTAToad]

True - it shouldn't be too much trouble to change

[Gary]

ah but if you wanted to follow true basic should it not be a : and not a ; between statements? I associate C with a ; at the end of a statement

But yes you are right it would make sense to do it that way if the function is in there anyway

[Slydog]

@Crivens: "However when it comes to keeping code size down and plonking"

I have to agree in principal. 
If you're a beginner (or others follow / read your code) then following standards is necessary.
But when you are a single dev with 30 years of experience, or part of a small group, I find situations where I break those standards, for code readability / simplicity, etc.

My biggest 'no-no' is using the GOTO statement.  (but rarely)
You don't have to lecture me on why not to use it, and I KNOW how to avoid using it . . . but sometimes it just makes the routines much tidier and easy to follow.
I use it to break out of some logic and / or to skip some logic.  Wrapping IF . . . ELSE . . . ENDIF code around it is the proper way, but then you compromise clarity.

The only reason it is 'wrong' to use it IMO is because it's very dangerous if you're not careful and most times it makes the code MORE confusing. 
And this brings me to my next point, beginners can't tell when its ok to use, so tell them never to use it.  Just like never start a sentence with 'And' 

Although I've never needed / wanted to use the IF . . . THEN as you are describing, I would have expected it to work how you expected (ha, as is the standard).

[Crivens]

Actually one of the main languages I've worked on over the years on Unix systems is one of the Business basics (IBM made the most famous apparently but you will have almost definitely never heard of it despite it being around for decades and part of the file handling routines apparently being put into Oracle), and this language always used semi colons as command seperators rather than colons and we've used the same language since about 1987 or even earlier from the previous company.

And if you want to push it, our ancient Unix basic even has proper line numbers 10 PRINT "HELLO"; GOTO 10. Actually one of our programming standards is to use GOTO. Main reason was the original standards were written 20 years ago (amongst other things there was only 65k a program, there is over 6000 programs, and as it turns out it was the fastest loop you could do in this particular language. They found years ago a typical overnight data rebuild or report with millions of records to process could have the time slashed quite significantly by using GOTO rather than any other loop. That and using proper file pointing and using numerics rather than strings. Just saying...

Infact that brings up an important point. It's always a good to test out a language for speed. Is it quicker to use while rather than repeat, do numerics work faster than strings, can a GOTO speed your loop up? Etc. It might not matter but on the other hand it might make the difference when you need an extra few fps or need a smoother look. Anyone done any speed testing for GLB?

Cheers

[Moru]

There is lots of speed testing on the forums. The catch is that different platforms does differently well on things. For example iPhones does much better with polys than drawing all sprites with drawsprite. Most handhelds aren't so good with floating point as with integers or 32 bit numbers at least. So basicly, if you have questions on what is faster, just test it on your target platform and figure out. Then post on the boards to let the next poor bastard not have to run the test :-)

[hardyx]

IF <condition> THEN <instruction>

Instruction is only one instruction, not many instructions separated by ";". If you want many instructions use the multiline version. I think the classic BASIC sentence "IF ... THEN inst1: inst2: inst3" in one line is weird and prone to errors.

[Crivens]

Well for syntax sake it is necessary. Every basic I've ever used considered the single line IF to have an automatic ENDIF at the end of the line, not the first command. If you are going to use multiple commands on one line then I would find it really weird not to execute every command on that line if started with an IF. As a comparison the most used Basic in the world (VB) works this way.

Why do you think it would cause errors?

Cheers

[hardyx]

Is prone to errors when you read the code, because you expect the instructions to be grouped in structurated blocks: While...Wend, If...Endif, etc. I think is a legacy BASIC instruction that can be implemented. But you can break the existing GLBasic code, because works different.

[Crivens]

But you can break the existing GLBasic code, because works different

Granted. But it is only prone to errors because you expect it to work that way because GLB has always worked incorrectly to other basic syntax. Every other basic works a different way and anyone used to other basics would be prone to errors as it currently stands for the very same reason.

Perhaps an option to automatically include ENDIF on an IF THEN line only at the end of line rather than end of first command would be a good idea. That way any legacy code would work (by switching to end of first command) and anyone new to GLB, used to other basics (and I'm really thinking VB here as it's the most used by far) will not have problems. This would make it the same as the declaring variables option. Most old code on this site falls over because of that. Turn the option off and all is good.

Any thoughts Gernot?

Cheers