Re: [UV] Variable never assigned a value warning
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
RE: [UV] Variable never assigned a value warning
Actually Bill, PI/open and Prime INFORMATION (last couple of releases) had meaningful run-time and compile-time error/warning messages. Very similar to your examples with the variable/constant names. The online help also gave you more info for the error code that it displayed (sometimes useful :-)). Regards David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill H. Sent: Thursday, March 04, 2004 5:41 AM To: U2 Users Discussion List Subject: RE: [UV] Variable never assigned a value warning Marco: A useful alternative, which noone has ever fixed in over 25 years, is the message: [B10] in program "MyProgram", Line 106: Variable has not been assigned a value; zero used. or [B10] in program "MyProgram", Line 106: Nonnumeric where numeric required; zero used. Why in the world hasn't it been fixed to display: [B10] in program "MyProgram", Line 106: "InvoiceNo" has not been assigned a value; zero used. or [B10] in program "MyProgram", Line 106: "InvoiceNo" = "A"; Nonnumeric where numeric required; zero used. Stupid questions for the exasperated business developer? Bill -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
RE: [UV] Variable never assigned a value warning
Marco, At that point I wasn't really adressing your question. Sorry for taking the thread off it's original topic. I probably should have started my own thread. Hey, it's all Martin Phillips' fault. His "Incidentally,..." paragraph got me off on a tangent, onto a soapbox. It's a sore spot where I keep getting poked. cds > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Marco Manyevere > Sent: Wednesday, March 03, 2004 8:18 PM > To: U2 Users Discussion List > Subject: RE: [UV] Variable never assigned a value warning > > > My query is not on how to suppress the warning messages but > on why the compiler catches only a few of them. Even the > case statement example you gave is in my opinion a good > candidate for such warning messages because a robust program > would have to provide for a default case block, something like: > > LOOP >GOSUB ASSIGN.A >BEGIN CASE > CASE A = 1; B = 'Apple' > CASE A = 2; B = 'Orange' > CASE A = 3; B = 'Banana' > CASE 1; B = 'Something is very wrong here!' >END CASE >DISPLAY B > REPEAT > > Regards, Marco > > "Stevenson, Charles" <[EMAIL PROTECTED]> wrote: > HEAR, HEAR! > > > 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
RE: [UV] Variable never assigned a value warning
My query is not on how to suppress the warning messages but on why the compiler catches only a few of them. Even the case statement example you gave is in my opinion a good candidate for such warning messages because a robust program would have to provide for a default case block, something like: LOOP GOSUB ASSIGN.A BEGIN CASE CASE A = 1; B = 'Apple' CASE A = 2; B = 'Orange' CASE A = 3; B = 'Banana' CASE 1; B = 'Something is very wrong here!' END CASE DISPLAY B REPEAT Regards, Marco "Stevenson, Charles" <[EMAIL PROTECTED]> wrote: HEAR, HEAR! > 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
RE: [UV] Variable never assigned a value warning
> The easy answer is no. This would require the compiler to establish all > possible paths through a program and determine whether it was possible to > arrive at any place that uses a variable without setting it > first. Although > some compilers (many C compilers for example) make a good attempt at this, > there are always cases that cannot be resolved. You seem not to have compiled Java code then as I can't think of a situation where the comiler would miss the slightest opportunity to complain about the possibility that a variable or object might be unassigned ;-) ** This email message and any files transmitted with it are confidential and intended solely for the use of addressed recipient(s). If you have received this email in error please notify the Spotless IS Support Centre (61 3 9269 7555) immediately who will advise further action. This footnote also confirms that this email message has been scanned for the presence of computer viruses. ** -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
RE: [UV] Variable never assigned a value warning
> Is it technically or theoretically possible for the BASIC > compiler (or any other compiler for that matter) to catch > (during compilation) all the situations that might result in > the use of unassigned variable at runtime within the scope of > the subroutine being compiled? It's not exactly an answer, but one useful thing the compiler does currently allow is the "-X" option to generate a symbol map. "BASIC BP XYZ -X" generates BP.L XYZ which has shows a cross-reference map of where each variable is assigned or used. I typically search for variables that are assigned but never referenced, referenced but never assigned, or look for patterns of use that might tell me something, such as variables you meant to use in one section, yet unexpectedly crop up in the map somewhere else. Misspelled variables stick out like sore thumbs. Comparing the map of the old version to that of the new can be useful. cds -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
RE: [UV] Variable never assigned a value warning
Marco: A useful alternative, which noone has ever fixed in over 25 years, is the message: [B10] in program "MyProgram", Line 106: Variable has not been assigned a value; zero used. or [B10] in program "MyProgram", Line 106: Nonnumeric where numeric required; zero used. Why in the world hasn't it been fixed to display: [B10] in program "MyProgram", Line 106: "InvoiceNo" has not been assigned a value; zero used. or [B10] in program "MyProgram", Line 106: "InvoiceNo" = "A"; Nonnumeric where numeric required; zero used. Stupid questions for the exasperated business developer? Bill > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Martin Phillips > Sent: Wednesday, March 03, 2004 12:42 AM > To: U2 Users Discussion List > Subject: Re: [UV] Variable never assigned a value warning > > > Marco, > > The easy answer is no. This would require the compiler to establish all > possible paths through a program and determine whether it was possible to > arrive at any place that uses a variable without setting it > first. Although > some compilers (many C compilers for example) make a good attempt at this, > there are always cases that cannot be resolved. > > As a very simple example, consider the following: > > BEGIN CASE >CASE A = 1 >B = 'Apple' >CASE A = 2 >B = 'Orange' >CASE A= 3 >B = 'Banana' > END CASE > DISPLAY B > > Clearly, if A is not 1, 2 or 3 B will not be assigned when we get to the > DISPLAY statement. But, the compiler cannot treat this as an > error/warning > because the author of the program may know that A can only have these > values. We do not want to have to set variables explicitly for cases that > cannot happen. > > 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 I am told that a UV user somewhere has asked for > this trap to be optional. I wouldn't like to try to support their code! > > Martin Phillips > Ladybridge Systems > 17b Coldstream Lane, Hardingstone, Northampton NN4 6DB > +44-(0)1604-709200 > > - Original Message - > From: "Marco Manyevere" <[EMAIL PROTECTED]> > Subject: [UV] Variable never assigned a value warning > > > > Hi All, > > > > Is it technically or theoretically possible for the BASIC > compiler (or any > other compiler for that matter) to catch (during compilation) all the > situations that might result in the use of unassigned variable at runtime > within the scope of the subroutine being compiled? Under what > circumstances > does the compiler catch or fail to catch such situations? > > -- > 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
RE: [UV] Variable never assigned a value warning
HEAR, HEAR! > 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
Re: [UV] Variable never assigned a value warning
Brian, Actually, I felt the same way for a long time (about Borland compilers) but once I gave in to the bullying, I developed a new set of habits in coding variables which I then carried back into mv. I'm not sure I can articulate the difference, but it has been a good decision. - Charles "I ASSIGNED IT, STOP COMPLAINING" Barouch Brian Leach wrote: Marco, The problem is that all it can do is warn that there *might* be a route through that would not assign a variable, depending on conditional logic. The Borland compilers do this - and boy is it annoying. For example, you might have a case statement that handles each potential and predictable input to a routine. Depending on the logic this migh lead to a variable referenced later on, based on the result of that case statement, being seen as potentiall unassigned (since the compiler doesn't know the possible incoming values). So it warns you that the variable might not be assigned. So you then pre-assign the variable to remove that warning, and the compiler then complains that this assigned value may not be used! Duh! The real problem is that over a large Delphi project (some of our components run into hundreds of thousands of lines of code) you can get so many unnecessary warnings like this that you might lose a legitimate warning amongst them. Less of a problem on U2 where you are not linking so much code into a single routine, but potentially annoying all the same. Brian Leach -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marco Manyevere Sent: 03 March 2004 06:32 To: [EMAIL PROTECTED] Subject: [UV] Variable never assigned a value warning Hi All, Is it technically or theoretically possible for the BASIC compiler (or any other compiler for that matter) to catch (during compilation) all the situations that might result in the use of unassigned variable at runtime within the scope of the subroutine being compiled? Under what circumstances does the compiler catch or fail to catch such situations? Regards, Marco - 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 __ __ This email was checked by MessageLabs SkyScan before entering Microgen. This email was checked on leaving Microgen for viruses, similar malicious code and inappropriate content by MessageLabs SkyScan. DISCLAIMER This email and any attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information. In the event of any technical difficulty with this email, please contact the sender or [EMAIL PROTECTED] Microgen Information Management Solutions http://www.microgen.co.uk -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
RE: [UV] Variable never assigned a value warning
Marco, The problem is that all it can do is warn that there *might* be a route through that would not assign a variable, depending on conditional logic. The Borland compilers do this - and boy is it annoying. For example, you might have a case statement that handles each potential and predictable input to a routine. Depending on the logic this migh lead to a variable referenced later on, based on the result of that case statement, being seen as potentiall unassigned (since the compiler doesn't know the possible incoming values). So it warns you that the variable might not be assigned. So you then pre-assign the variable to remove that warning, and the compiler then complains that this assigned value may not be used! Duh! The real problem is that over a large Delphi project (some of our components run into hundreds of thousands of lines of code) you can get so many unnecessary warnings like this that you might lose a legitimate warning amongst them. Less of a problem on U2 where you are not linking so much code into a single routine, but potentially annoying all the same. Brian Leach > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Marco Manyevere > Sent: 03 March 2004 06:32 > To: [EMAIL PROTECTED] > Subject: [UV] Variable never assigned a value warning > > Hi All, > > Is it technically or theoretically possible for the BASIC > compiler (or any other compiler for that matter) to catch > (during compilation) all the situations that might result in > the use of unassigned variable at runtime within the scope of > the subroutine being compiled? Under what circumstances does > the compiler catch or fail to catch such situations? > > Regards, Marco > > > > > - > 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 > > __ > __ > This email was checked by MessageLabs SkyScan before entering > Microgen. This email was checked on leaving Microgen for viruses, similar malicious code and inappropriate content by MessageLabs SkyScan. DISCLAIMER This email and any attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information. In the event of any technical difficulty with this email, please contact the sender or [EMAIL PROTECTED] Microgen Information Management Solutions http://www.microgen.co.uk -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
Re: [UV] Variable never assigned a value warning
Marco, The easy answer is no. This would require the compiler to establish all possible paths through a program and determine whether it was possible to arrive at any place that uses a variable without setting it first. Although some compilers (many C compilers for example) make a good attempt at this, there are always cases that cannot be resolved. As a very simple example, consider the following: BEGIN CASE CASE A = 1 B = 'Apple' CASE A = 2 B = 'Orange' CASE A= 3 B = 'Banana' END CASE DISPLAY B Clearly, if A is not 1, 2 or 3 B will not be assigned when we get to the DISPLAY statement. But, the compiler cannot treat this as an error/warning because the author of the program may know that A can only have these values. We do not want to have to set variables explicitly for cases that cannot happen. 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 I am told that a UV user somewhere has asked for this trap to be optional. I wouldn't like to try to support their code! Martin Phillips Ladybridge Systems 17b Coldstream Lane, Hardingstone, Northampton NN4 6DB +44-(0)1604-709200 - Original Message - From: "Marco Manyevere" <[EMAIL PROTECTED]> Subject: [UV] Variable never assigned a value warning > Hi All, > > Is it technically or theoretically possible for the BASIC compiler (or any other compiler for that matter) to catch (during compilation) all the situations that might result in the use of unassigned variable at runtime within the scope of the subroutine being compiled? Under what circumstances does the compiler catch or fail to catch such situations? -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
[UV] Variable never assigned a value warning
Hi All, Is it technically or theoretically possible for the BASIC compiler (or any other compiler for that matter) to catch (during compilation) all the situations that might result in the use of unassigned variable at runtime within the scope of the subroutine being compiled? Under what circumstances does the compiler catch or fail to catch such situations? Regards, Marco - 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
