In continuing to maintain legacy code ( which must run for the next 18 months at a minimum ), we have occasionally hit the Foxpro 2.6 development error:

PROGRAM TOO LARGE

In later versions of Fox, the message was enhanced to read:

PROGRAM IS TOO LARGE

Either message really means that there are at least 65,537 bytes of "real" code -- comments and blank lines don't count.

Today's example involved an offending function ( 3,626 lines of code ). Extracting that function from its PRG "home" and compiling it, yields an FXP file of 78,061 bytes. Recompiling with NODEBUG ( to remove the LINENO() value from the code ), yields an FXP file of 72,252 bytes. This final figure is still 6,716 bytes over the "magic" number of 65,536 bytes. I know that the minimum FXP compiled from a PRG with a single * ( asterisk ) is 134 bytes from Foxpro 2.6 and 148 bytes from VFP 8.0, so I would expect some overhead, but there is an average of 1.85 bytes per line of code extra.

QUESTION: Are there guidelines for projecting the "program size" ?

PS -- our current reactive model is to isolate code into UDF's, making sure to predefine variables to PRIVATE scope so they may be referenced in the new UDF as well as the existing code. This is pragmatic, but plays havoc with delivery schedules on "minor" fixes, which become a couple hours of work. In other words, we ain't dead yet, but would like to proactively look at the biggest modules and with some pre-planned effort reduce or eliminate these surprises.

PPS -- No mocking please! One of the values of FOX has been its continued support for legacy code, allowing time for upgrade and redeployment ( which is going on here ), while not shutting down the ongoing operation.