>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,
I disagree with the set filter part. Agreed, it shouldn't be used in place of a p-view or sql select but there are times when you need to set a filter - for instance a have a report cursor with a parent-child relationship. The parent cursor has multiple records but I only want the report to run for one parent record at a time (due to business rule/system requirements/faxing compatibility etc.) so my only choice is to set the filter to the unique key of that record, run the report, then turn the filter off.
Setting a filter on an optimizable expression shouldn't hinder performance with smaller recordsets.
I also see a place for public variables in saving and restoring SET settings when an app starts/ends.
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.
