Hi Jim,

Do with it what you will :-) I would go against limiting to 20 words; I think some concepts have to be explained.

>Was going to snatch all these little goodies and drop them in a word doc to post on our bulletin board. However, a permanent UT reference would be ideal.
>Call it "VFP Dos & Don'ts" and restrict each "commandment" to 20 words. If the commandment requires explanation, make one of the 20 words a hyperlink to the explanation.
>
>Thoughts?
>
>
>>Hmmm...maybe I will. There are a lot more "no-nos"... just can't remember them 'till I see them in code :-)
>>
>>>I agree with all of your statements.
>>>
>>>Maybe it should be created on the UT so that all can add to it or at least have a reference to it for the future?
>>>
>>>
>>>
>>>>Hi All,
>>>>
>>>>Jim's PANDA post about public variables and the fact that I have spent some mentoring time lately compels me to write this list:
>>>>
>>>>

Don't use PUBLIC variables. They're hard to track down and not good design. Use object methods. This is Jim's mantra and a good one.
>>>>

Don't use Formsets. Formsets suck. Formsets are the black holes of VFP objects; hard to manage and impossible to escape once you've used them.
>>>>

Don't overload your Form.Refresh. Too much logic in Form.Refresh slows down an app considerably. Especially try to avoid requerying or SCAN type ops in Refresh.
>>>>

Use type and object prefixes! It's not that hard to get in the habit of and it makes your code a helluva lot readable.
>>>>

Forget SET FILTER. SET FILTER can slow down your app much worse than a parameterized view.
>>>>

Don't forget your SETs. Remember to set your SETS in the BeforeOpenTables event of a DataEnvironment when a form uses a Private Datasession.
>>>>

Parameterized views require parameters! If the parameter is a Form property, then the view will error on opening unless you've set NoDataOnLoad for the cursor to .T. You can requery in Form.Init to get the proper rows.
>>>>

All tables should have primary keys! All of them. No exceptions to this rule. None. Ever. For any reason.
>>>>

Avoid code repetition. If Apply and OK buttons both save code, then they should call a common method to save.
>>>>

Consistancy! Think long and hard about right-click and dbl-click behaviors for controls. Be prepared to explain why clicks act differently for different instances of the same control type. DOCUMENT those differences with ToolTips.
>>>>
>>>>There are doubtlessly a gazillion other no-no's.........

------------------------------------------------
John Koziol, ex-MVP, ex-MS, ex-FoxTeam. Just call me "X"
"When the going gets weird, the weird turn pro" - Hunter Thompson (Gonzo) RIP 2/19/05