Understanding the Scope of Variables

A scope is a section of code, from which you can 'see' a variable (i.e, assign it a value, or read its value). For example:

sub foobar(x as byte)

dim i, y as byte

y = x * 30

for i = 1 to y

dim r as short

r = x + 5

next i

r = x + 5 ' this would produce a compiler error

end sub

So, in the example above, x and y could be seen from anywhere within the sub procedure called foobar. However, r could be seen only from within the for... next statement. Thus, trying to assign r a value from outside the for... next statement would result in a compiler error, because it actually doesn't exist outside of that loop.

One identifier can refer to several different variables, depending on the scope in this identifier is used:

dim x as byte ' this creates the variable x in the global scope.

sub foobar(x as byte) ' here we create x once more, in the scope of the local sub (x as an argument).

dim f, y as byte

x = 5 ' right now, only the locally-created x (foobar agrument) equls 5; global x remains unchanged.

y = x * 30

for f = 1 to y

dim x as byte

x = 30 ' the argument x outside the for... next statement still equals 5. only this local x equals 30.

next f

end sub

Every compilation unit has, in itself, one global scope. Variables declared in this scope are accessible from within any sub or function in this compilation unit.

dim s as string

sub foo

s = "foo" ' assigning a value to the global string variable s.

end sub

sub bar

dim i as short

i = 0

s = "" ' initialize s, in case it contains anything already (such as 'foo').

for i = 1 to 5

s = s + "bar" ' note

next i

end sub ' at this point, s contains 'barbarbarbarbar'.

This is the scope which is between the beginning and the end of each of the following statements:

Beginning	End	Notes
sub	end sub	Cannot be nested.
function	end function	Cannot be nested.
for	next
while	wend
if... then... else	end if	No exit statement for if... then... else.
do	loop

Variables declared in this scope are accessible from within the construct in which they were declared. Local scopes may be nested, for example, for...next scope inside sub...end sub scope.

A locally defined variable with the same name as a global variable takes precedence in its context over any variable with the same name which is defined in a 'wider' scope.

sub prc1(x as byte)

'some code here

end sub

sub prc2

dim prc1 as byte 'define a local variable with the same name as one procedure we have

prc1=0 'this will generate no error -- in the current scope prc1 is a variable

prc1(2) 'here, we try to invoke sub prc1 and this will cause a compiler error.

end sub

This is a special scope, implemented in Tibbo Basic. HTML files included within a project may contain embedded Tibbo Basic code. This code is executed when the HTTP server processes an HTTP GET (or POST) request. Statements within an HTML file are considered to be within one scope -- similarly to a function or sub scope, with the exceptions that include and declare statements are allowed.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">

<HTML>

<BODY>

BEGINNING OF OUTPUT

include "global.tbh"

declare i as integer ' i is defined somewhere else

for i = 1 to 10

Foo

next i

END OF OUTPUT

</BODY>

</HTML>

Designing dynamic HTML pages always presents you with a choice: what to do- include the BASIC code right into the HTML file or create a set of subs and functions and just call them from the HTML file? In the first place you put a lot of BASIC code into the HTML file itself, in the second case you just call subs and functions from the HTML file. So, which way is better?

Generally, we recommend to use the second way. First of all, this style of programming is cleaner- a mixture of BASIC code and static HTML text usually looks messy. Second, the second method consumes less variable memory.

Although the HTML scope is similar to a local scope of a function or a sub, its variables get exclusive memory allocation as if they were global. When you avoid writing a lot of BASIC code in the HTML file itself you usually avoid having to create a lot of variables in the HTML scope and this saves you memory!