code analysis tools for MV. do they exist?

[BillH]

Though not new to MV, we have been spending quite a time with MS
VisualStudio and have been taking advantage of a tool from NuMega
(Compuware) called DevPartner. It has lots of lovely things like
checking for unused/unassigned variables, logic errors, unused
subroutines/tags, memory leaks, bounds checking, etc.

This many years later, has anyone written a code analysis tool that
would report back such valuable information in the UniVerse/MV space?
I have seen the usual (albeit dated) pre-compilers, etc. but they
don’t seem to go this deep. Lately, we have had a slew of errors occur
in the field due to complex code snags, variables assigned within a
conditional statement but re-used elsewhere (#1 ill) and others of its
kind. All of these in Universe end in a program debug/break. When you
use a browser as the front end that, of course, ends the conversation
rather badly.

Our choices seem to be compile the code with an option so that debugs
do not occur (and, thus, suffer the consequences of where the newly
assigned null variable takes you) OR keep flogging the programming/QA
staff until they find every permutation of logic path. It seems a code
analysis tool ala NuMega would be welcome. They were not to warm to
the idea of adding support for UniBasic so I wondered if others have
made their own versions or know if such tools exist for our platform.
thanks

[Douglas Tatelman]

Hi Bill,

I know this isn't exactly what you want, but I've been able to use the
BSYM file in classic Pick to detect unassigned variables and easy
errors like that.

We could definitely use a more verbose compiler option.

[mvdbman]

If you're talking just UniVerse and not lumping UniVerse and MV
together, the U2 Basic Developer Toolkit (BDT) for UniData and
UniVerse is available for UniData 7.2 and UniVerse 10.3. I have not
used the tool yet but if I remember the demo correctly, I believe it
might meet your requirements.

Anyone, please correct me if I'm wrong!

Bruce H

[Peter McMurray]

Hi
bsym from the compiler is handy but isn't it time that you started coding to
standards preferably using a 4gl. We also used map a lot in the early
Reality days to get efficient layout of arrays.
So in D3 COMPILE BP PROG (MX) or (MXO) surely U2 has something similar.
As for turning off error messages all I can say is that in the early days it
was known as the Sue Me option as it was option S on a Reality. Not a very
bright idea I think.
The very first rule that I learned in my first programming class was
"Initialise everything"
The second was
"KISS"
I have seen some spectacular stuff-ups through failure to follow these
rules. I do remember a 1000 line include at one place that called routines
elsewhere in the overall program. Quite spectacular.
Small self contained sub-routines are essential for manageable code.
Peter McMurray

[Tony Gravagno]

Have a look at mvScan:
http://www.brianleach.co.uk/pages/mvscan.htm

[Jeff K]

We have experienced the same issues when a subroutine that's called
from the web crashes. You do have to be careful in those, and to
test, we write a driver program to exercise the routine from the
command line. We create the test driver in a different file, and just
add "TEST." to the front of the actual subroutine's name. The test
program becomes your unit test, and can run as many different
scenarios as you like. When one fails, you can isolate the test
scenario that failed and step in with a debugger to see what's
happening. It's not the best debugging technique I've ever used, but
it gets the job done.

I work with Unidata, not Universe, so this may not apply exactly to
your situation, but I imagine that there would be a similar feature in
Universe. In Unidata, compiling with the -X option produces a
variable cross-reference that really shows a lot of detail about the
variables in your program. You can see variables that were never
assigned a value, but used anyway, or the opposite, variables assigned
a value but never used otherwise. It also includes line numbers in
the source code where each variable is used, assigned, etc. In
Unidata, there's also a "TO {filename}" option you can use to keep the
cross-reference files out of your source files.

At a minimum, I'd require your developers to take a look at the xref
file before putting a program up for production, but you could also
write an automated analysis tool that looked for common errors.

There isn't enough info in the files to do any analysis of the logic
flow, so it won't help with the case you mentioned where the
assignment was in an IF statement that didn't get executed, then the
variable was referenced later anyway.