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

[Zack]

I see. And I also assume that the reason it's been made to be rather complex is so that it can inhabit a mere two lines. Is that correct? It could be done in a less concise, but clearer way. Perhaps I'll attempt that tomorrow.

[stylin]

Well, many seasoned programmers aim for terseness when writing code, usually because this leads to clearer, and sometimes more elegant, code. Terseness, however, can be a liability; it took me a few minutes to decipher (pun intended) his algorithm, and I would have appreciated a short comment. It can be digested, if chewed.

In his case, I think splitting up the loop would actually make the code less clear, since it would detract from the main things that are being accomplished: 1. calculating an encryption key, and 2. encrypting the text. Splitting it up, IMO, would require additional helper functions, so that the encryption code could be kept on the same level of abstraction (1. and 2., instead of 1a., 1b., 2.).

[na_th_an]

I just drop by to say that I strongly discourage following this direction:

2. Declare variables only when you immediately need them, ie., not all at once at the top of the program.

No-no. Spaghetti, spaghetti.

[Anonymous]

in a language like qb, na_th_an is correct. however, now that we have fb (and variable scoping) you can definitely declare vars when you need them, and safely let them go out of scope when they aren't needed anymore.

[na_th_an]

For scoped variables, yes. But I can picture people declaring *any* stuff wherever and then losing track of variable types and stuff.

I fiscourage it.

[stylin]

For scoped variables, yes. But I can picture people declaring *any* stuff wherever and then losing track of variable types and stuff.

I fiscourage it.

The key here is initialization - and efficiency. You don't want to declare variables in a function that might exit before they're even used - it's a waste. Furthermore, whenever possible, it's preferred to intialize variables, rather than declaring them and assigning to them later - again, it's a waste. When FB supports classes, this will be even more of an issue: a class' constructor might be an expensive operation to execute. Why construct it to default values only to overwrite those values in an assignment later? It's a waste; it's inefficient code.

Spaghetti code is non-intelligible wild-goose hunts, and it mainly refers to erratic control flow - it has nothing to do with when or where variables are declared. In C, you're forced to declare variables at the start of a function. QB, FB, C++, Java, etc. give you the option - and it's an option you must take if you want to write efficient - and sometimes safe - code. Hell, by default, QB and FB don't even require you to declare variables before use - and it's directly supported by the language!

For beginners and novices alike in the above languages - yes, QB too - I fully encourage variable declaration at the point of initialization. For QBers, this means declaring a variables immediately before their first use. It's just silly not to, IMO.

[na_th_an]

Let me quote myself: "For scoped variables, yes"

Note that FB is not a OO language. When it is, maybe it's good. But now, it can be puzzling. 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.

Note that declaring a static variable and giving it a value is not a waste, no matter where it is declared/initialized. It is allocated on a static data "segment" (to call it somehow) at compile time, so that means that:

Code:

DIM a AS INTEGER

IF foo THEN
   INPUT a
   a = a + 7
END IF

Code:

IF foo THEN
   DIM a AS INTEGER
   INPUT a
   a = a + 7
END IF

Will take the same space and be as fast. 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.

A very different thing is the scoped usage of variables in OO languages, or even pseudo OO ones. For example, a loop index variable is really handy to be declared in the very loop, for example in Java:

Code:

for (int i = 0; i < 100; i ++)
{ ... }

In that case, you know that "i" will be int just inside the brackets. But 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

[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

[na_th_an]

Sometimes you have really long functions (even longer if you do profusely comment!), and you can't split them. Take for example a fast syntactic analyzer. The fastest way to create it is with a SELECT CASE structure and a different entry for each keyword.

Note that I am an optimization and speed freak. Sometimes the "best looking algorithm" and the "best split function" are also way slower than uglier counterparts. When I coded my last finished QB game (i.e. Jill) the movement subroutine took up to 400 lines or so. I could've split it in subroutines, but the amount of data needed to be passed back and forth would have turned the process into a snail walking over sand :lol: That's why my code style is not always very ... rational.

Besides, I'm working now doing lots of web-coding mostly in Java, JSP and PHP, and I can assure you that you will find 1,000 lines functions quite easily :lol: specially when you have html rendering plus database handling plus open directory reading plus connection to a mail server plus call to a PDF generating library all in place (I mean, just the calls to all those subsystems take lots of lines - I just wrote a SQL query that took 15 lines five minutes ago ).

I think I'm missing something. What I claim is for declaration on top of your function/sub or main section. I am not encouraging module globals.

You claim to declare variables when they are used. And you talk about scope. As far as I know (correct me if I'm wrong, I've been several months unaware of additions to fB), then only way you have to isolate visibility in BASIC is inside a FUNCTION or a SUB. In C++ or Java you have your brackets so you have a perfect way to isolate chunks of code - this makes your life easier. In this case, I find extremely useful declaring and instancing objects when they are needed, in the fashion of:

Code:

if (iConnectorStream != null)
{
   StatementGenerator myGenerator = new StatementGenerator (blah, 1);
   ...
   // Here you can use myGenerator
}

// Here myGenerator is not declared

But in BASIC this is not possible (again, AFAIK ). Until it is, I'll keep declaring my stuff on top of each SUB/FUNCTION.

I suppose it's a matter of taste, but I find it more comfortable having all my declarations packed in a special section in the code rather than scattered around thousands of lines plus I don't see the advantages of what you are suggesting, mainly 'cause you can't isolate chunks of code.

[red_Marvin]

Maybe it would be good to have this in fB:

Code:

SCOPE
  DIM foo as integer
  '...
  ' foo available
END SCOPE
' foo not available

EDIT: According to stylins's post it is being implemented...