>>>>>Just want to point out that my code for splitting a procedure file into individual PRGs is now in the Thor Repository. My article about it, including the reasons I don't like procedure files, is here: http://www.tomorrowssolutionsllc.com/Articles/Splitting%20a%20Procedure%20File.PDF
>>>>
>>>>Having a common utils.prg allows encapsulation, a single place to search for the function you need.
>>>
>>>No. Encapsulation is a runtime consideration. Storing stuff in a drawer is not encapsulation.
>>
>>Encapsulation is considerate of both types (in a single file, in a compiled app).
>>
>>VFP traverses each file it stores individually when searching for the function. It searches by name, then by the procedures within. It would not surprise me to learn that VFP actually compiles .PRG files written like this:
>>
>>

* myprog.prg
>>&& real program content here

>>
>>As though they were written like this:
>>

* myprog.prg
>>
>>FUNCTION myprog
>>&& real program content here

>>
>>And then to find that myprog.prg, it actually looks for myprog as a top-level procedure / function name performing its procedure / function search. Just a guess, but given that the need to search for functions / procedures exists, it is a natural use of that ability.
>>
>>>>When trying to find your missing function use Tools -> Code References and search for "FUNCTION myFuncName" and you'll find it quickly ... if you truly don't know where it is.
>>>
>>>I always know where it is. It is in myfuncname.prg
>>
>>Me too. It's in utils.prg. I even have a hot key to be used when you're on a function to load:
>>

ON KEY LABEL F12 KEYBOARD "{Ctrl+LeftArrow}{Ctrl+Shift+RightArrow}{Ctrl+C}{Ctrl+F2}{Ctrl+F2}MODI COMM progs\utils.prg{Enter}{Ctrl+F}FUNCTION {Ctrl+V}{Enter}"

>>
>>:-)
>
>You're confusing the location of the code with the functionality of the code. There is no benefit to the code at runtime if they are stored in a single .prg. My testing of calling separate prgs in an exe versus calling them in a function library shows there is a difference. Further there was a time when having a .prg that started with a function declaration of the same name was slower.
>
>Also - in the virtual world of software, I can simply x=date(). Why must people arbitrarily aggregate bits of code like they are books in a library?

There is only one strong reason for doing this (bundling multiple functions into one PRG), and it would be to implement abstraction / polymorphism.

You would create the same function in two different PRGs:
EmployeeProgs.PRG -> FUNCTION Save
CompanyProgs.PRG -> FUNCTION Save

If you are in the Employee.SCX, you set procedure to EmployeeProgs.PRG
If you are in the Company.SCX, logically set procedure to CompanyProgs.PRG

Both screens can be generically calling SAVE(), while obviously the actual actions are different from each other.

So if someone were to create a procedural code, that would be the way to go. Of course it does not make sense because with OOP you have much better ways to accomplish this, but in theory that is the one case where you cannot work with separate PRG's.