>Mike,
>thanks for the input. I have received different opinion on this. I guess I will continue the way I have with large .PRGs staying separate and small ones that get called from more than one place going into the procedure files. With the power of today’s PCs I lean towards the solution that is the easiest to maintain. It does no good to have a program that runs really fast but crashes a lot and you can't figure out what in the spaghetti code is causing it.

I know you received different opinion, and it was wrong. Look at the whole picture for a second. Say I join your team and I want to find a function referred to by some piece of code. Without asking for help, having to look in documentation or doing a text search, how do I look at that function's code? If it was a separate PRG, it's a no-brainer. Can't get much easier than that. Spaghetti code will be spaghetti no matter where the routines are. I believe it will be messier spaghetti when two copies of the same function exist in two different procedure files. That is an accident I'd rather avoid.

When you work by yourself, it may seem sensible to put stuff in large procedure files, but it rarely makes sense in a team. Sure, there are other programs that try to integrate the changes from multiple developers, but that's just another place for things to go wrong in my book.

>
>>Hi John
>>
>>Having many procedures in one file versus having many separate prgs makes no performance difference in an exe/app. Although, having to SET PROCEDURE in the first place takes time.
>>
>>It does make a difference when not using an app/exe because the files have to be located along the search path.
>>
>>>Does anyone have any idea if there is any perfomance difference between putting many programs in a procedure file or just leaving them as seprate programs? We have two procedure files. One holds all the general utilites such as converting number to words for checks, etc. The other is specific to each system and holds things like validating invoice numbers, etc. These files have become large even though we only put mostly small functions in them and this causes them to become hard to maintain. Getting to the 32nd function that starts on line 6532 can be a pain after a while.