>Well I may not use English well. I use "personal preference" to mean "though I don't agree your way to be right I respect your ideas. You do it your way and I do it my way. No need for an endless discussion. Neither of us would be convinced:)"

You use English well enough. I respect your opinion. If I did not respect your opinion, I would not see any benefit to discussing this with you. I am willing to let you try to poke holes in my argument because I may be wrong and hope to learn from you. I am willing to be convinced.

There should indeed be discussion. There is a problem that needs to be solved. The problem is a lack of planning in the organization of software modules at design time. Can you tell me where I would put a function called Weekdays? I believe it should be it's own .PRG. Your first attempt SHOULD be to MODIFY COMMAND WEEKDAYS. So with no thought you can find my .PRG. You need only to guess the name of the function - which should be obvious. Just as with a language, the word ball represents a physical ball. The name of the function must represent the function. You should not also have to guess where it is stored.

What is the best form of organization? There is a spectrum of everything in one classlib to one class per classlib. In a single developer shop, it would probably be OK to put everything in one classlib. In a multi-developer shop it would quickly become really awkward.

Which approach works in both a single developer and a multi-developer environment? The answer should be obvious.

I already know I cannot find your classes - without reading through documentation - if there is any, or asking you. If you leave the company before I start there, I'm screwed. I may chose to just build another one. If I need to fix yours I will have to find it, check it out of source control, make the change, recompile not just that one function, but the entire library, test it and then hope it checks back in to source control. Conflicts with other developers changing that library can require me to manually intervene in the integration process. There are workarounds, like text searchers and merging, but they are just workarounds.

We don't build database multi-user applications that way! The user does not get the entire DBF file sent to them, change it, and then we examine the entire file to reintegrate those differences. In a properly normalized table such conflicts rarely happen. The record is the lowest common denominator in a table. The file is the lowest common denominator in a file system.

Assuming everything is left broken down, I can categorize and cross-reference the functions in many different ways. You could categorize them your way and I could categorize them my way (if we think differently) and neither of us would be hindered by the physical arrangement.


>Cetin
>
>>I don't understand the use of "personal preference". Personal preference applies IMO to things that I like without really thinking it through. Things like how I take my coffee. It rarely applies to technical matters.
>>
>>For instance, if someone says it's their personal preference to put big half inch gobs of solder when assembling a circuit board that doesn't mean he's doing the right thing.
>>
>>>Personal preference.
>>>BTW I don't see weekdays function related to Payroll screen. I mean classes that are really related.
>>
>>I know they are not related. That doesn't stop people from coding it that way. Things get lumped together BEFORE any real thought goes into the organization.