Hi Jeff,

>Let's be careful not to generalize. I wouldn't say "FORGET SET FILTER" or "NEVER USE PUBLIC VARIABLES". Instead, "LIMIT USAGE OF SET FILTER AND PUBLIC VARIABLES". Without seeing the specific situtation and business contraints that a particular app funcationality faces, you can't say that using Set Filter and public variables is inherently bad.

The point of list like this is to generalize. When one is learning something, (programming style, how to paint, play the piano, drive, you pick it) generalities make it possible to learn quickly--but at the cost of only learning the basics. As you progress you learn when to break the rules--but you have to know them first.

I would guess that great painters, and musicians break a lot of rules that they learned as apprentices. In fact, if they do it convincingly enough, new schools of thought, and new rules get created in their name. But, they had to learn the rules first.

Mikhail Tal, who was the world champion in chess for one year (1960-61), was one of the great attack players, and reknowned for breaking the conventions of chess. His rival Mikhail Botvinnik made great contibutions to theory, and strategic chess. When Botvinnik won the title back from Tal, it was said that chess students all over the world were relieved because they could stop trying to learn Tal's, "method" (he was a brilliant tactical player, and seemed to be most content to play into odd positions so he could start cooking up combinations) and get back to learning strategic chess. I guarantee though, that Tal knew all the "rules" before he learned to break them to set up his attacks.

John's list, and Jim's "No Public Memvars" maxim are rules of this nature. I have waded through bad code (a lot of it my own) and seen where a list of do's and don'ts, had they been followed would have made a world of difference.

In short, simple rules make for better guides. When the time comes to break them, you will know it, and you will have the knowledge, and the experience to have taken the consequeses of breaking them into account.

So in the spirit of the thread, I offer this addendum:

"Don't break a rule unless you know why you are breaking it."

Best,
Bill