>I know you toungue in cheek with this, but I would like to comment anyway.
>
And I thank you for it.
>
>>1. The rules change, and you do not have the time to know what the lastest fad is.
>
>Fads are fads and rules are rules and never the twain shall meet. The rules of sound relational datase design were set in the 70's and they remain unchanged. The rules of OO analysis, design, and programming were set down in the 70's and 80's and they remain unchanged.
>
... except that no two books on the subject share the same rules, definitions etc. Face it Jim, there is no Codd and Date when it comes to OO.


>Some simple rules that will never change;
>
>Loose external coupling is better than tight external coupling

That's the basis of structured design, and here's a rule I abide to religiously.
>
>Encapsulation of data and behavior is better than separated data and behavior
>>Methods of objects are better than UDFs as they allow the encapsulation of data with the behavior.

When applicable. There is a price to pay in terms of modeling that is only paid back if reuse is guaranteed. Which in the real world (and I'm talking about the domain here) is not frequent.

>Properties of objects are better than variables floating around in memory
>PUBLIC variables stink, they should be avoided at any cost.
>Globals should be limited to the fewest as possible.
>
Basic xBase hygiene I'd say.

>Any project will be as good as the analysis and design.

With all due respect, this is an easy one :)

>
>Tomatoes are fruit and potatoes are vegetables even though they both end with toe
>
This one on the other hand I like.
>
>>2. A lot of rules do not really have a reason to exist
>
Kind regards,

Marc