>>Hi Albert
>>
>>I strongly believe such a functions should be their own .PRG. If naming it is hard, imagine the added difficulty of trying to remember both the name and in what library to find it! Not only that, but you never even need a set procedure to to use it. That seems to me to make it even easier to use!
>>
>>It certainly should be a name that is explicit for the return value. You call the function for it to return something. You can comment the header of the function with keywords so you can find it again later, whatever you call it.
>
>Why not create a procedure file for all functions that manipulate a parameter? It could contain functions like asc2hex(), str2num(), whatever. If I do not immediately remember the name of a specific function, I probably do immediately remember that it will for sure be in that specific procedure file.
>
>Since we have the set proc ADDITIVE keyword there's no longer an excuse to put all stuff in only one procedure file. And performance is not the issue here.
>
>I agree with your notion that the usage of the returned value should be of influence on the name. Sometimes it's even handy to have a function that simply calls another function, just to create a sensible name.

It's actually the name that I'm concerned about. If I put this function inside that procedure library, the name becomes (in a sense)

procedurefile.function. It is harder to me to remember the procedure file name.

In effect, I see the little .PRG as a pure extension of VFP. It is simply another function immediately available to the language without having to find it buried someplace. It is exactly like being able to use VFPs ALLTRIM function. How much purer can you get?