>>>There is only one strong reason for doing this...
>>
>>This is what's called "an opinion." There are other strong reasons for bundling multiple functions into one PRG.
>>
>>Your arrogance and belief that your conclusions are the only viable ones is really something.
>
>With strong I did not mean you should not do it in other cases, but I meant you cannot accomlish this doing it a different way.
>
>I can see that there are other reasons to bündle functions anyway you wish, it greatly depends on which strategies you are using to maintain source code, or the type of projects you work on.

I like the class designer (properties window). It's an excellent way to visualize your code. However, it doesn't work with PRGs. I've never particularly liked the DEFINE CLASS structure in a PRG file either. I see value in that you can have encapsulation within encapsulation (one class.prg with multiple class definitions contained within), but I do prefer the single PRG with multiple related functions within.

I also like PRG files rather than VCX or SCX files because you can use traditional file sharing utilities like git and do diffs on them, whereas in their binary form not so much. FOX2BIN is a good utility to go back and forth to obtain diffs, or to check in source code versions of your *.?CX files, but it requires the extra manual processing step (even if done in automation).

>My point was in this one case there is no alternative, simply because you cannot create two prg's with the same name, the VFP compiler would only take one of the two files, according to my Knowledge.

Correct. Most people would call them by a larger name, like custsave.prg, or inv_save.prg, etc.

By creating a customer.prg and an invoice.prg, with all of the related functions contained within, it makes it clear what is calling what where and when ... at least that's been my experience. That kind of encapsulation makes the project have fewer files, and each file relates to its specific task, and common algorithms are placed into common.prg, or utils.prg, or whatever is appropriate based on their context.

It's a design I've used for a long time, though I still use SCX and VCX design methodologies daily as well. It depends on the task... for mostly data processing, encapsulated PRG files with functions within, for utility functions used everywhere utils.prg, for common code related to data processing common.prg, and for visual things SCX or VCX. It's a design I've used since VFP3 (in varying evolution), and it's one that works well, is intuitive, and is easy to extend / pickup by newcomers.