Author |
Topic: List Variables Utility (Read 1060 times) |
|
Michael Hutton
Developer
member is offline
Gender: 
Posts: 248
|
 |
List Variables Utility
« Thread started on: Mar 5th, 2009, 01:34am » |
|
I am currently working to update VarList207.bbc to a utility that could be added to the Utilities dropdown menu of the BB4W IDE.
If people have used this and like it (or don't like it) could they post suggestions in this thread?
Of particular interest to me is *how* they would like *what* information to be displayed..
Any other suggestions are also welcome.
Michael
|
|
 Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: List Variables Utility
« Reply #1 on: Mar 5th, 2009, 08:52am » |
|
Quote:| If people have used this and like it (or don't like it) could they post suggestions in this thread? |
|
I must confess I haven't used it, and no doubt I could find out the answer myself if I downloaded it, but I would be interested to know to what extent it performs the functions I suggested way back in November 2006:
"Create a cross-reference listing showing where each variable is defined and used (by line number or function/procedure name). Report cases of variables which are defined but never used, or used but never defined. Issue warnings for 'risky' practices such as using the same variable name for both a global and a local variable."
Richard.
|
|
Logged
|
|
|
|
Michael Hutton
Developer
member is offline
Gender:
Posts: 248
|
|
Re: List Variables Utility
« Reply #2 on: Mar 7th, 2009, 08:15am » |
|
I have been working on this a bit over the weekend as my diving trip was cancelled due to a tropical cyclone! (Harriet or something)
Stupidly though I have forgotten to bring my USB with it to this computer so you'll all have to wait with baited breath to see it!
As to:
Quote:| Create a cross-reference listing showing where each variable is defined and used (by line number or function/procedure name). |
|
I have updated it to use a tree view to list all the functions and procedures, and within each node is a Global or Local node with a list of the variables of each type. It doesn't tag where each global variable is defined (by line number) as it walks the program line by line rather than follow the program flow. It would be relatively easy (I think) to be able to add a line offset or number when a variable is first encountered...
Quote:| Report cases of variables which are defined but never used, or used but never defined. |
|
Geoff Gibson et al have included ways of detecting if prototype structures are not found.. I can guarantee that works..as to other variables I'm not quite sure how that could be achieved without running the program.
Quote:| Issue warnings for 'risky' practices such as using the same variable name for both a global and a local variable. |
|
At present it issues warnings for variables which might clash with a Keyword token. I think I could add a flag to show when a LOCAL variable has the same name as a GLOBAL variable. I must admit though I do that a lot with the static variables as 'normal' practice.
Anyhow, I will pop back and get my USB and download a development version to show what I have done so far. (It still works by reading a saved file) As yet I have not seen the checkquotes code..
Michael
|
|
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: List Variables Utility
« Reply #4 on: Mar 7th, 2009, 09:50am » |
|
Quote:| I'm not quite sure how that could be achieved without running the program. |
|
Depending on how sophisticated the syntax analysis is, it ought to be possible to determine whether a variable name is used in a context when it can be created ('L-value') or read ('R-value'). A variable name that only ever occurs as an R-value is probably an error. One that only ever occurs as an L-value is suspicious and ideally should be flagged as a warning (although it may be deliberate, such as an unused value returned from an API call).
The BB4W documentation lists the L-value cases here:
http://www.bbcbasic.co.uk/bbcwin/manual/bbcwin2.html#creation
Quote:| I must admit though I do that a lot with the static variables as 'normal' practice. |
|
It would be reasonable to treat the static variables as a special case, although personally I think it's rarely desirable for them to be used as globals.
Richard.
|
|
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: List Variables Utility
« Reply #5 on: Mar 7th, 2009, 10:15am » |
|
Quote:
On a (very) quick test it seems to do 'what it says on the tin'. Are the lists in the right-hand panel just the 'global' variables, or are they all the variables? If the latter, is there a way of getting a list of just the global variables?
This is not in any way intended as a criticism, and the utility is after all described as a 'variable lister', but I suppose what I was hoping for is more something that would draw attention to possible errors in my programs. So I would ideally have preferred more emphasis on checking things like GLOBALs and LOCALs sharing the same names, variables written but never read etc. rather than a simple list.
Richard.
|
|
Logged
|
|
|
|
Malcolm
Guest
|
|
Re: List Variables Utility
« Reply #6 on: Mar 7th, 2009, 2:15pm » |
|
Just my two pennyworth.
The cross reference version did list the variables by PROC name giving the Globals that it used and the Locals/Private it used. I think I did that part very simplistically taking the Local list away from the total list for that PROC and calling the remainder Global. Thus if there was a Local with the same name as a Global it would show as Local which it is. I think a warning or highlight could be produced by comparing the two lists.
The main list was of ALL declared and used variables categorized by type. The ('L-value') or read ('R-value') was never assigned. I don't think all possible cases of 'R-value' were even looked for, only most of the possible 'L-values' with the exception of declaring as an address of, as stated 'on the box'.
Indeed I am not sure that in some cases it doesn't rely on the R-value for detection. Thus to do the 'not declared' or declared but not used' warnings, which would be nice to have, would take a bit of reorganization and extension.
Does a list of all the 'R-value' situations exist somewhere?
It could potentially advise against Globals with lower case beginnings and Locals that are Capitalized or any other naming 'rule' that might be considered good form, including the use of statics as Globals. (Which I tend to do on small programs)
Malcolm.
|
|
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: List Variables Utility
« Reply #7 on: Mar 7th, 2009, 5:57pm » |
|
Quote:| Does a list of all the 'R-value' situations exist somewhere? |
|
Any variable that isn't an 'L-value' must be an 'R-value'! The only other case is a 'declaration', but that only applies to arrays and structures (i.e. DIM).
Richard.
|
|
Logged
|
|
|
|
Michael Hutton
Guest
|
|
Re: List Variables Utility
« Reply #8 on: Mar 8th, 2009, 12:41am » |
|
Quote:Are the lists in the right-hand panel just the 'global' variables, or are they all the variables? If the latter, is there a way of getting a list of just the global variables?
|
|
At the moment it is a list of ALL variables. But a list of just the GLOBAL can be achieved.
Quote:This is not in any way intended as a criticism
|
|
Please bear in mind that this is version 0.0000....0001! and all I have done so far is to add an interface I thought might appeal to people.
Quote: draw attention to possible errors in my programs. So I would ideally have preferred more emphasis on checking things like GLOBALs and LOCALs sharing the same names, variables written but never read etc. rather than a simple list.
|
|
This is the next step. I think Malcolm and Geoff Gibson has done most/all of the hard work and I just need to collate the results as it were.
Quote:The cross reference version did list the variables by PROC name giving the Globals that it used and the Locals/Private it used
|
|
You can expand the tree view to look at the variables inside the PROC/FNs
Thank you for the suggestions. It is exactly what I need to make sure I hit the mark!
Michael
|
|
Logged
|
|
|
|
Michael Hutton
Developer
member is offline
Gender:
Posts: 248
|
|
Re: List Variables Utility
« Reply #9 on: Mar 10th, 2009, 01:47am » |
|
I think I have reached the limit I can 'Update' VarList207. I'm not sure what the right word for it is but the code is getting more and more complicated by trying to add features on top of someone else's program! I have successfully been able to put bugs in but not get rid of them!
Anyhow, I am now working on a complete re-write. It includes.
1. Ability to update to work with the IDE.
2. A new structure based Linked list - which therefore makes it 'expandable'
3. Update of a few 'bugs' noticed in VarList207, or rather style issues.
4. A simple syntax checker - version 0.0001!
5. Very heavily commented code!
Michael
|
|
Logged
|
|
|
|
Malcolm
Guest
|
|
Re: List Variables Utility
« Reply #10 on: Mar 10th, 2009, 03:36am » |
|
Here are some issues that I found in the cross reference that I did.
Single line DEF PROC and Functions in the main body of a program don't show correctly. This could be fixed by looking at the end of the line that starts with a DEF to see if it is indeed a single line Definition. And it would need a second list to capture the variables it contained. The original design flushed out the list of variables each time it hit a DEF. That would not be suitable as it could already be within another definition.
I can't think of any good way of dealing with multi DEF headed definitions that have a common body. And when does a Definition actually end? It depends on the program flow.
One thing I should have done differently is switch on the collection of Globals right from the start and print those out under a Main heading or something first.
Malcolm.
|
|
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: List Variables Utility
« Reply #11 on: Mar 10th, 2009, 10:25am » |
|
Quote:| This could be fixed by looking at the end of the line that starts with a DEF to see if it is indeed a single line Definition. |
|
Funnily enough I was thinking about this exact issue myself. You can't literally "look at the end of the line" in the case of a single-line FN, because (unlike a single-line PROC) the 'marker' for the end of a function - an equals sign in 'left' mode - isn't at the very end.
However you probably don't actually need to know that's it's a single-line PROC/FN as such. It's always necessary to treat lines beginning with DEF as a special case, because they are 'skipped' (treated as REMs) when encountered during normal program flow, so once you've taken that into account (properly!) I would hope that both single-line PROCs/FNs and 'multi-headed' PROCs/FNs (where there are multiple entry points) would 'fall out' of the natural working of the lister.
Here is an example which could be used for testing:
Code:DEF PROC1 : LOCAL A
LOCAL B
B = G
DEF PROC2 : LOCAL C : C = B
LOCAL D
D = C
DEF PROC3 : LOCAL E : E = D : ENDPROC
LOCAL F
F = E
ENDPROC
This is what the lister should report:
PROC1 has local variables A, B, D and F. It references 'global' variables C, E and G.
PROC2 has local variables C, D and F. It references 'global' variables B and E. It doesn't reference A or G at all.
PROC3 has local variable E. It references 'global' variable D. It doesn't reference A, B, C, F or G.
Because a variable can be 'global' to a PROC/FN without actually being a global (!) my recent thinking has been that one needs to think in terms of listing four categories of variable:
* Genuine 'globals', which are referenced outside any PROC or FN.
* Genuine 'locals', which appear in a LOCAL statement.
* Genuine 'privates', which appear in a PRIVATE statement.
* Variables that are referenced in a PROC/FN but which don't appear in a preceding LOCAL or PRIVATE statement (in that PROC/FN). The program may not be able to tell (reliably) whether they are genuine globals or not.
Note that, in the same PROC/FN, a variable can be both a genuine LOCAL/PRIVATE and in the fourth category, if it is accessed both before and after the LOCAL/PRIVATE statement!
Richard.
|
| « Last Edit: Mar 10th, 2009, 10:30am by admin » |
Logged
|
|
|
|
Malcolm
Guest
|
|
Re: List Variables Utility
« Reply #12 on: Mar 10th, 2009, 5:37pm » |
|
If you were stupid enough to declare a Private and a Local variable in a Procedure with the same name. What priority does BB4W give.
Malcolm.
|
|
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: List Variables Utility
« Reply #13 on: Mar 10th, 2009, 11:08pm » |
|
Quote:| If you were stupid enough to declare a Private and a Local variable in a Procedure with the same name. What priority does BB4W give. |
|
There's no 'priority' as such: each statement will be executed independently, as and when encountered by the interpreter. Whether the variable behaves as a LOCAL or as a PRIVATE when subsequently accessed will depend on which statement was last executed.
It's not even necessarily "stupid" (although there would need to be code accessing the variable in between the LOCAL and the PRIVATE for it to do something useful).
It's entirely possible (if unusual) for the same variable to be listed as being LOCAL, PRIVATE and 'global' all in the same PROC/FN!
|
|
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: List Variables Utility
« Reply #14 on: Mar 11th, 2009, 09:13am » |
|
How about this for a bit of amusement:
Code: REPEAT
PROC1
WAIT 10
UNTIL FALSE
DEF PROC1
PRIVATE A%
A% += 1
PRINT A%;
PRIVATE A%
A% -= 1
PRINT A%
ENDPROC
Two independent PRIVATEs with the same name!
Richard.
|
|
Logged
|
|
|
|
|
