>>The downside - for me - to place each function/procedure in a separate .PRG is a maintenance headache. I have not counted but the application probably has a couple of hundred procedures. And having to scroll through this list in the project manager (if necessary to look at the code of whatever), would increase the time of maintenance. I know many will say that instead of the Functions/Procedures I should have them in classes. And maybe so. But I started this application way before I knew anything about how to build classes. When I can and when it makes sense, I do refactor the code.

"If it ain't broke, don't fix it" is a marvelous motto, as is "perfect is the enemy of good." ;-)

The other good (?!) news is that the arrival of VFP Compiler changes everything again. Most functions are split out into the C++ dll whether in SET PROC or individual prg, both of which cease to exist.

One reason to use Tamar's Thor routine to break large SET PROCs into individual prgs is that next time you rebuild the app, the Project Manager will include only those prgs that are actually used, not the whole forest from the SET PROC. So depending how many different purposes are packed into huge SET PROCs you may see smaller exes with smaller lists of procedures/functions internally which could affect performance.