But --when you return from vacation, of course-- could you point out an advantage of having multiple functions, each in their own prg? To me, that would be like having each article in an encyclopaedia in its own little pamphlet.
Back from vacation. I think the best way to answer your question is to turn it upside. What's the advantage of having all your functions in one enormous PRG that has to be pulled into every project that you write, whether you're using all the functions or not?
To answer more directly, here are some of what I think are benefits:
1) I'm fairly sure that separate PRGs are marginally faster (as long as you don't put a PROC or FUNC line at the top).
2) I find it much easier to manage separate PRGs. If I know the function name, I just type MC <function name> to open for editing. With a procedure file, I have to open the file and then use either Find or Document View to get to the right item.
3) VFP can be very weird about modifications to procedure files. I took over an app last year that has one big proc file. I kept finding that changes I'd make wouldn't show up in testing. Turned out that once I'd built that proc file into an EXE, VFP would always look for it in the EXE instead of the copy on disk. I had to delete the EXE to make my changes show.
Since no one else here jumped in and yelled, I don't think I'm alone in doing things this way. I suspect if you polled the pool of VFP writers and speakers, you'd find that almost all of them use separate PRGs.
One guy, Mike Yearwood, even believes that you should put every class in a separate classlib. I don't agree with him on that, but I do sort of see where he's coming from.
Tamar