>Larry,
>
>The issue is not whether you can find out who called, it is that needing to know who called weakens the internal cohesion of the called function. IOW, the called function must behave differently depending on who called. While this may not be an immediate problem it is certainly waiting to become a problem. As the system evolves, say a new function needs to call this one and it needs still a different functionality. With this approach, eventually, the called function will become a huge DO CASE construct with new cases being added for every new need. This will become a maintenance nightmare after a while.
>
>George's comment is based on the principle that a single function should do one thing very well and only one thing.
>
>The point being that simply needing to know who called is indicative of a faulty function design.

Without knowing the details of what the code is doing, I'm not sure that you can categorically make these statements. They seem to say that parameter passing should not be considered, as the parameters will affect what the function does. It may simply be that the requirement for knowing the calling program is just to put a message on the screen stating the calling program. The function is still doing just one thing, depending on the situation it may be more reliable for the function to determine for itself the calling program, rather than trust the programmer to correctly pass the information as a parameter. One situation that comes to mind is for error reporting, is it bad practice for an error reporting routine to determine as much information for itself, including the calling program, rather than rely on information passed by parameters, which could be passed wrongly (deliberately or by mistake).

It may be that what is being done is bad programming practice, but without details of what the code is doing, I really don't think someone should be told that he is using bad programming practices.