Just a Code Sample: EXIT SUB

[CharlieJV]

Code: QB64: [Select]

1. declare sub EvalInput(This$)
2. '
3. getinput: input "enter some alphanumeric text: "; a$
4. cls
5. call EvalInput(a$)
6. print
7. goto getinput
8. '
9. sub EvalInput(This$)
10.         if len(This$) > 4 then
11.                 print This$
12.         else
13.                 print "min length of 5 condition not met; hard exit"
14.                 EXIT SUB
15.         end if
16.         print "processing continued to normal subroutine end"
17. end sub

[bplus]

This is QB64 man! You don't have to Declare Sub nor "Call" Subs. :)

The IDE doesn't even cap Declare Sub, interesting...

[_vince]

This is QB64 man! You don't have to Declare Sub nor "Call" Subs. :)

The IDE doesn't even cap Declare Sub, interesting...

That sure is a lot of liberty, but where is the justice?

[SMcNeill]

That sure is a lot of liberty, but where is the justice?

If the weather at your home is like mine, all you have to do is look outside.  We didn't get any snow from this last storm.  It was all just ice.

[CharlieJV]

I probably should have mentioned.  Cognitive disabilities over here, so you're likely to find all kinds of strangeness in any of my code samples.

In particular, aside from general program structure: verbosity, because the visual cues are helpful "anchors", or points of reference.

Well, there is also me trying to maintain a certain degree of cross-compatibility as I try to get BASIC Anywhere Machine as reasonably possible compatible with QB64...


I'm a big fan of QB64.  For the benefit of other QB64 newbies/enthusiasts, please do point out whatever is unnecessary and/or generally bad practice for other folk.

[Bert22306]

This is QB64 man! You don't have to Declare Sub nor "Call" Subs. :)

FWIW, while I agree that having to declare all subs at the top was a bloody nuisance, "Call subfoo" is, IMO, way more readable, than just naming the sub. Especially when others need to read and understand your code.

[SMcNeill]

FWIW, while I agree that having to declare all subs at the top was a bloody nuisance, "Call subfoo" is, IMO, way more readable, than just naming the sub. Especially when others need to read and understand your code.

There was one big advantage to declaring a SUB up top: The actual Sub could then go anywhere in the code!

Declare Sub foo

CLS
PRINT "Hello";
foo
SUB foo
   COLOR 4 'Red color
END SUB
PRINT " World!"
END

The above runs just fine in QB45 and earlier, with the Declare setting the stage so the program knows references to foo are going to be addressing the Sub, letting you place it anywhere in your code after that.

Where this became especially helpful was in creating libraries, where you could then include the SUB with the declare, place it at the top of your code, and only need one $INCLUDE file.

QB64 doesn't work like this however, so our subs go into a .BM file and dims/types into a .BI, requiring us to have 2 $Include statements.

[Cobalt]

There was one big advantage to declaring a SUB up top: The actual Sub could then go anywhere in the code!

Declare Sub foo

CLS
PRINT "Hello";
foo
SUB foo
   COLOR 4 'Red color
END SUB
PRINT " World!"
END

Not exactly.
if you tried typing that in the QB45 IDE verbatim, you would receive an error;
  [ You are not allowed to view this attachment ]  

[SMcNeill]

Not exactly.
if you tried typing that in the QB45 IDE verbatim, you would receive an error;

The IDE moves SUBs to their own workspace.  Try to compile the program from the command line instead.  😉

QB45 has no issues with it, if you write the code in notepad or another editor.  It's just the IDE that's picky about separating the code.

[tomxp411]

FWIW, while I agree that having to declare all subs at the top was a bloody nuisance, "Call subfoo" is, IMO, way more readable, than just naming the sub. Especially when others need to read and understand your code.

Not really. While it can be used as a signal that the following symbol is a subroutine, it's mostly a waste of space. Its only syntactic purpose is to allow a function-style syntax when a value is not being returned. ie: CALL OpenFile(filename) as opposed to OpenFile filename.

More to the point: a SUB is really a new command. From the developer's standpoint, you're literally adding a new command to the language when adding a subroutine. In fact, most languages rely on this and don't have any internal commands, other than basic flow control. In C, for example, there's not even a PRINT statement. Instead, the printf() function is a library routine and not actually part of the language itself.

If it helps you in your own work, there's nothing particularly wrong with using CALL, but if you're working with other people, you'll probably find that it's not recommended. Microsoft still includes the CALL statement, but their documentation now says to use it only in specific circumstances, such as when an identifier starts with a character that is not a letter.

[_vince]

So everyone's getting on-board with OPTION _EXPLICIT but DECLARE is a waste of space..