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 developers in determining if their application has received 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 looking 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 implementation 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 another 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