Hi All [from John Koziol]:

Jim's PANDA post about public variables and the fact that I have spent some mentoring time lately compels me to write this list:

(HTML cleaned up 12/30 by anal-retentive web designer...)

1. 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.
2. 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.
3. 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.
4. 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.

   While I strictly follow this, it should be known there are great (not half-baked) reasons this is a bad logic. Read Charlie Schreiner's article from Aug. 1997's FoxTalk: "A cRose by any other oName" or Thread#258085 for more info. -MHelland

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

   SET filter has it's place in VFP development. Though it's true the SET FILTER can slow down your app in some cases (when rushmore can't be used), but in others they're far faster than parameterized views (Rushmore at work). There are also cases where P-views are not an alternative. Here SET FILTER comes in handy - Walter Meester

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

   I assume, we also can set our Sets in Form.Load() - NNosonovsky

7. 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.
8. All tables should have primary keys! All of them. No exceptions to this rule. None. Ever. For any reason.
9. Avoid code repetition. If Apply and OK buttons both contain save code, then they should call a common method to save.
10. Consistency! 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.
11. The default Windows Close button. For Pete's sake, use it! If a Form can be closed then enable the Close button. A lot of people make Closable = .F. yet put a Close or Quit button on a Form. Why??
12. For any full size app (little utilities etc. don't count) do NOT use the VFP base classes directly on your forms and form classes. Instead, subclass them all (and leave them default if you wish) and use those instead.

    except comboboxes: set BoundTo = .T. and never think about it again -- Garrett Fitzgerald

13. do not ever, ever unload foxtools (it's assumed loaded by default) -- Dragan Nedeljkovich

    What? I haven't used foxtools since VFP5! Who assumes it is loaded by default? -- Paul McNett

    I did not used them too... -- VladGrynchyshyn

14. Do not use underscores in variable and field names. It's hard to remember where you used them and where you didn't. -- Peter Robinson (Or at least be consistent about it) Yeah (to consistency), but I find in practice that it is a whole lot easier to consistently leave them out then to consistently put them in. PR
15. If you're doing general business development, do yourself a huge favour and buy (or at least evaluate) a commercial framework. Most come with full source code, giving you a look at the techniques used by some of the best developers in the business. -- Al Doman
16. Where possible, follow MS Windows Design Guide standards. It's what users expect in application look-and-feel. Also look at Alan Cooper's book, "About Face" for great information about what makes a successful GUI.
17. comment, Comment, COMMENT! Don't assume that you're the only one who'll ever need to read and understand your code. Giving meaningful names to Procedures, Properties and Variables also helps here. -- Larry Moody

    Not only Comments in code, but comments for properties and methods in the form and class designer, tables and fields in the table designer, and modules in the project manager. -MHelland

    And you will find soon that your comments are very useful for you... -- VladGrynchyshyn

18. Try to avoid multiple return statements, if, of course, it doesn't lead to much complexity. - Nadya Nosonovsky
19. Don't change settings rather than in Load or BeforeOpenTables methods. - Nadya Nosonovsky
20. If you want to perform exact match in your seek function, use SEEK PADR(field_name,field_len). - Nadya Nosonovsky
21. Use local tables when possible
22. When subclassing or making base classes, do NOT change properties that cause automatic resizing of control. For example, do NOT set AutpSize property of the checkbox - you will find that you cannot get rid of it even when you set it to .F. on the form. Do NOT set Integral Height of listbox. Its strange, but do NOT make a label class with right or centered alignment - you will find that labels moves around without any reason. -- VladGrynchyshyn
23. Do NOT try to discover wheels and jump higher self. Just ask question at the UT and you will get answer in 99.9% ;-) -- VladGrynchyshyn
24. Use ActiveX controls, specially such as TreeView, ImageList, TabStrip. They enhance application interface a lot with little cost, and sometimes even help to solve some problems. -- VladGrynchyshyn
25. Read FAQ and other resources befor asking question. Remember that other people have too a lot of tasks to do, so don't take valuable time for questions that you can find answer by self. -- VladGrynchyshyn
26. Never allow a user to modify a PK; use a surrogate key instead. Also, avoid using compound expressions for PK's; slows performance and hard to maintain.