Not to mention the infidel CLEAR statement that does the same thing, hides errors.
I believe the practice of variable assignment at the top is a practice brought over from other languages where all variables apparently need to be defined up front with DIM statements and variable types. I support some QB & VB code and don't think twice about introducing the variable mj late in the program for a local test and not DIMming it at the front. Come to think of it, those systems tend to have an implied CLEAR as from out of nowhere, you could have PRINT A and the unassigned value of A would be zero (it's a numeric variable). You could also PRINT A$ and get nothing wrong. Hell, you even get the first 9 or 10 array elements without even using a DIM to dimension. PRINT A$(6) would yield null as well without being previously defined. Perhaps the early defining of variables is a discipline that was taught but not really required. I shiver when i see the CLEAR statement when the program needs my assistance. I relucantly comment it out while reviewing to see if that's the cause of an unexpected value somewhere. More often than not, after compiling and when run the first time with no CLEAR, I get distracted by some other errmsgs unrelated to the problem at hand. I relegate that command to the lazy category. I've never used it in all my years of MV. my 2 cents. > > Incidentally, I find the worryingly common practice of > > setting all variables to zero / null at the top of a program > > very annoying as it hides the very useful unassigned variable > > trap, leaving you thinking your program works when actually > > it doesn't. > > > > Martin Phillips > > Ladybridge Systems > > > Yes, this practice HIDES real errors. > > I too see it a lot, and I think it is absolutely disgusting. > Maybe the practice originated with programmers who were used to working > in languages where they had to declare variables & var types at the top > of their program. They just felt kinda naked without saying, > I=0;A='';[EMAIL PROTECTED], at the top of their basic code. A poor reason. > > Don't do it. > > Be aware that the *occasional* such message may hint at a *multitude* of > unreported error incidents. Especially when the error is deep inside an > important loops. Let me illustrate by expanding Martin's example: > > LOOP > GOSUB ASSIGN.A > BEGIN CASE > CASE A = 1; B = 'Apple' > CASE A = 2; B = 'Orange' > CASE A = 3; B = 'Banana' > END CASE > DISPLAY B > REPEAT > > You will get an "unassigned error" message only if A just happens to not > be 1,2,or 3 on the very FIRST pass through the loop. Subsequent passes > where that occurs would use the value assigned to B on the previous > iteration. UV will be happy to do so. > > Initializing B at the top of the program, above the loop, would > eliminate those occasional error message but not eliminate the buggy > code or a fundamental logic flaw. > > Try to initialize & assign variables exactly where they apply. Then > watch for error messages that point out your flaws, and be grateful for > them. > > Chuck Stevenson > -- > u2-users mailing list > [EMAIL PROTECTED] > http://www.oliver.com/mailman/listinfo/u2-users > > --------------------------------- > Yahoo! Messenger - Communicate instantly..."Ping" your friends today! Download Messenger Now > -- > u2-users mailing list > [EMAIL PROTECTED] > http://www.oliver.com/mailman/listinfo/u2-users -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
