Dragan --

Yes, I can see how your approach to skipping those continuation lines is quite simple. However, I've gotten really good progress, with a simple stand-alone program, using the output from Code References. I can't see that I want to go through the effort to learn how to export everything to a DBF merely to handle the continuation line problem.

As for code looking different when treating it like data -- well, I actually have my entire history as a VFP programmer to look through, and there are still remnants from my first few months of programming, as well as everything in between. Some of it pretty scary stuff. But enlightening, too, to see how far I've come.

Jim


>>Dragan --
>>
>>Your approach made me wonder why I couldn't do the same thing using Code References -- but without the need to analyze all code in .PRG files and the like. (Fairly sure I could do it if needed, also fairly sure it would take me a while.)
>>
>>Instead, I've been working on a solution that looks more or less like:
>>
>>(1) Using Code References to find all lines containing WITH, ENDWITH and RETURN
>>(2) Export to a DBF
>>(3) Analyze the results with a single pass through the file (essentially mimicking your sample code).
>>
>>This seems to work fairly well (so far).
>>
>>I've noted that
>>(1) I only search for WITH, ENDW and RETU, since these abbrevations are allowed. I avoid them, but that's not true for all code I've gotten from other places.
>>(2) There's some possibility for "false negatives", as I have lines that begin with a difference usage of WITH:

 Replace all SomeField;
>>with SomeValue

Again, not the way I would write code now, but I must have done so in the past.
>That's easy - check for continuation lines like this:
>
>skip while right(alltrim(line),1)=";"
>
>Of course, that's for the original "all code in a dbf" approach, not the "take code ref's output" approach. But code references can help you know which pieces of code to look for.
>
>>I've actually found 137 possible problems that I must investigate; most look like real problems that will need to be corrected.
>
>Doesn't even your own code look quite different when you start treating it like data :).