>>>Please, for the sake of peace, let's just ignore those. He does provide good food for thought.
>
>I have no problem with that and I definitely agree he provides good food for thought.
>
>>I'm glad you said that. I too would like to aim for engineering. I just saw on one of the mail lists how someone has pages and pages of code in a single PRG. He has one missing ENDIF and he can't find it. To me it must be an engineering principle to aim for the atomic so as to prevent that kind of thing.
>
>I can relate to that. I am maintaining an app for a client that is built on SBT/Accpac/Sage Pro Series. 5 - 40K line PRGs are common. IF statements that span hundreds of lines are common. Bad variable naming is common. Bad temp table/cursor naming is common (a_tmpf1, a_tmpf2, etc. instead of meaningful names about what that table/cursor contains). I could go on . . . and I will! . . . the interface drives me nutty and is not anywhere near modern. Some days I want to shoot myself.
>
>And I do remember that you didn't like the name of my IsFieldInTable function and it can be looked at as poorly named. I believe that originally it did only that - return true or false to give you the answer you desired. But I really don't have much call for this function. I know some apps never use it. I think that one day I also needed to know the field position and I decided it was reasonable to pass back the field position (or -1 if it does not exist), which tells you two things via one number: does it exist and what position is it. I guess I decided not to rename the function. But this is an exception. I work hard on procedure/function/method naming to make the code clear and concise, but make no claims to perfection.
>
>>Oh, yeah and the VCX is an atom too. IMO a vcx should contain 1 class with rare exceptions.
>
>Well, I don't do that. What are the benefits of this, in your opinion? I know one would simply be that when using the class in an app, you can use the only one you need and not bring along a bunch of unneeded code, but what other advantages do you see?

1 - multi-developer situations. Less conflicts - less need for source control merging functions - another avenue for problems.

2 - the goal is to create small discrete bits of code - for use at runtime. How is that goal supported by having hundreds of classes in a vcx / udfs in a prg at design time? A single endif being misplaced breaks massive parts of the system?

> I might do that in some situations, but for something like the subclassing of the VFP base classes, I can't see putting each control in its own VCX. Most developers will put those classes in one VCX and actually I've not seen anyone take it to the one class per VCX technique that you mention.

I know. Most people seem to prefer long complex undecipherable strings of nested functions to UDFs also.