The LA Fox Developer Newsletter

March 1995

Software Metrics (Con't from page 6)

STORE 1 TO i

DO WHILE LEN(SYS(16,i)) <> 0

STORE i+1 TO1

ENDDO

src = iif(line_num>O,program(i-3),”Command Wind”)

scrcode = iif(

if crntwind 1= “Command Window”

insert into errhand (user, date, time, app, program,;

errornum,errormsg,code,currdbf,linenuin,;

topwind,appsttime, errtime), values (MUSER,;

dateO, timeO, gcappname, src,errnum,ernnsg;

codeine,cdbf,line_num, crntwind, gnstart, secondsO)

select errhand

curobj = _curobj

~‘— Save a .MEM file in the memo field...

save to memo memvar

*_ record current status and memory listing.

logenvmt()

use

endif

This program is all that is required to track the

errors occurring in your system. As the table gets

more populated, queries start to become quite

useful in determining where the trouble spots are.

For example:

SELECT program, count(*);

from errhand;

into table prgerrs;

group by program

will tell you the error count by program.

Program Usage

This topic has been of great interest to many devel-

opers in determining if their application has re-

ceived adequate test coverage. The USAGE.APP

file presented here, will first scan all of your source

code and log into a table all of the procedure and

functions in the entire app. It does this by opening

up your project file as a DBF and scanning it look-

ing for all project elements with a type of “P” or “s”.

This table can then be exported for use at runtime.

The runtime portion logs into this table each and

every call made to each procedure. The implemen-

tation looks like this:

FUNCTION GETPRGS

=Iusage(sys(16))

The structure of susage.dbf is:

progfile C 12

procedure C 10

callcnt N 6

The function lusageO, opens up the table susage.dbf,

which is the table produced by the step discussed

above, It then locates the record passed to it by the

sys(16) function. Once found, the field CALLCNT is

incremented by one. This function call is necessary in

all functions and procedures to accurately record

application usage. Once testing has begun, you can

print out a bar graph showing the usage of all the

procedures in the application. The bar graph is a

simple Foxpro report that displays the prg file, any

functions contained in it, the call count, and a bar

representing the count scaled to the maximum value

found in the susage.dbf table. The expression that

produces the bar chart is:

replicate(”0”,int(callcntl(lnmaxval/80)))

In case the bar graph character does not reproduce

correctly in transmission, it is ASCII character 178. The

80 in the expression represents the maximum number

of graph characters that can fit on the page. This

report produces a bar chart with the bars running

across the page and the programs listed down the left-

hand side. This way the graph can continue on an-

other page and can accommodate any number of

procedures/functions.

The visual insight this bar graph report gives into

program usage can be quite valuable. Very quickly

you are able to determine what programs are being

used heavily and what programs are not being used at

all. Maybe it is dead code or maybe it was just never

tested. Without a tool like this, you would not know

until it comes times to deliver your app to a client. I

attach this program to a custom main menu pad so

that is available at any time just by selecting it off the

main menu. This program is a small part of a much

larger data dictionary application that I have written

which I will also be putting up on Compuserve, and

shortly the Internet. The dictionary works in a similar

way. It open up the project file and completely dissects

your project into every component. It logs in tables,

screens, reports, programs, table views, screen views,

(Con't, page 8)

Page 7