Here's another....file I/O difficulties.

[stylin]

Imagine that you, by mistake, declare the same variable twice in two distant points in the same "visible zone". The compiler will complain on the second, and you'll have to examine your code line by line to find out where the first was.

This gets us into an entirely different - although important - discussion. I'll be brief.

First, if a function is big enough to where you lose track of variable declarations - that is, the size of the function is such that it is non-trivial to find a particular variable declaration - then the function is too large; refactor it into seperate, smaller functions. Good functions are no more than 15-25 lines, a reasonable size for a language like BASIC. If your functions are larger, then they are probably carrying too much responsibility, and would benefit from being split up. This not only solves the problem of having acres of code to sift through the same scope, but also documents your code better, providing clear and descriptive comments for the functionality of your code in the form of function calls.

Second, if you find yourself running into name collision within a function, that's a clear sign that a) you may not need to declare another variable, b) you may need to provide a better name for the variable or c) the function is too large and is carrying too much responsibility - refactor into seperate functions. I see all three of these symptoms of less than ideal code all the time in QB and FB. There's simply no reason for it. Any reasonably written function that's under 25 lines should never suffer from name collision. If you do, then the problem is likely a) or b). Refactor. Additionally, in a well written function, variable declarations should be easy to find since the function is short enough to be seen as a whole at a glance.

In short, I see name collision and "variable-hunting" non-issues with well written code. (and one of the ways well written code is made possible is by Designing-Before-Coding®. A programmer with a plan rarely runs into issues such as these. I don't remember the last time I had a name conflict, except with language keywords - and that's FB fault, not mine :-?)

A different thing is dynamic structures, but I'd rather declare them on top, then initialize them when needed. That way you, at a sight, have all the stuff controlled. No need to fetch every variable declaration accross thousands of lines of code.

Again, you shouldn't have to search through thousands of lines of code for a local variable of all things. Why would you, anyway?

... in fB, if you do:

Code:

DIM i AS INTEGER
FOR i = 0 TO 99
   ...
NEXT i

After the loop, i keeps being defined as integer. Unless I am missing something

No, you're right. That is a problem, and I've already asked v1ctor over at freebasic.net for this:

Code:

for i as integer = 0 to 420
   ...
next

Hopefully that will make it into the next official release. I cross my fingers