LoginLogin

Shouldn't we always close quotation marks?

Root / Programming Questions / [.]

TheV360Created:
I keep looking at people's code and find lines like this:
PRINT "Hello, world!
Yes, it works, (due to a bug in SmileBASIC) but shouldn't we always close quotation marks in our code?

I keep looking at people's code and find lines like this:
PRINT "Hello, world!
Yes, it works, (due to a bug in SmileBASIC) but shouldn't we always close quotation marks in our code?
1. Its not a bug, reading the manual clearly says you dont need the other ". 2. If lets say we need to put text in a different place it can help a bit. 3. Its faster to use.

I keep looking at people's code and find lines like this:
PRINT "Hello, world!
Yes, it works, (due to a bug in SmileBASIC) but shouldn't we always close quotation marks in our code?
I've always thought about this too.

Here's why this works: When SmileBASIC encounters a line-ending character (CHR 10) when parsing, any open string on that line is automatically closed. This was just a design choice in the compiler (not one that I agree with though.)

I keep looking at people's code and find lines like this:
PRINT "Hello, world!
Yes, it works, (due to a bug in SmileBASIC) but shouldn't we always close quotation marks in our code?
1. Its not a bug, reading the manual clearly says you dont need the other ". 2. If lets say we need to put text in a different place it can help a bit. 3. Its faster to use.
Yes, but it looks horrible, it's a bad habit to make, and you need to end the quotation marks to use the ;. Also, what do you mean in #2?

Agreed, it's okay for quick-and-hasty tests, specifically direct mode, but should never be abused in a real program. Strictly talking about "best practice", we all know that it works.

I think that the string-reading termination should occur strictly with a closing ". It would be better practice and people could make multi-line strings. There are many design choices that I disagree with.

Here's why this works: When SmileBASIC encounters a line-ending character (CHR 10) when parsing, any open string on that line is automatically closed. This was just a design choice in the compiler (not one that I agree with though.)
I'm writing a ptc interpreter right now, I don't think it's a bug, I think it's just an oversight that was left in because there's no reason to take it out. When I implemented printing strings it basically goes through the code and adds things to a stack, when it evaluates a "FDSF" string (as opposed to a U$ string) it goes through everything in the code and adds it to the stack, when it reaches the length of the code sent to the string parsing function it throws an exception and returns the stack, so ending quotes are not particularly necessary. You would have to add code to make it not work. Personally I like it, ?" is a super convenient way to print text. (Is ? still in the 3ds version? idk), there are only a couple commands in the entire language that break when you stack them on the same lines with :, IF THEN ELSE, REM, and PRINT ", and maybe something else I'm missing. I don't mind it because it's not a total bogey, you just have to be kind of careful with them. Even if you fixed PRINT " you would still have a couple other unstackable commands so I don't see the point in fixing it.

I agree, I think it's simply bad practice and makes the code look more sloppy.

snip
I didn't say it was a bug, I said it was a specific compiler feature. You would be in best practice to reproduce this ability if you're making your own compiler.

Just to clear something up: This is not a problem with the PRINT statement. It is a problem with string literals. There are ways other than PRINT that a line can end in a string literal:
S$="ABC
B%=S$[0]=="A
GOTO "@L

there are only a couple commands in the entire language that break when you stack them on the same lines with :, IF THEN ELSE, REM
As I have said, this is not a command that is broken, it is the handling of string literals, which is categorically different. As for IF-THEN-ELSE, and REM, things would be (more) broken if : worked the other way.