> Today I use VFP to improve my own productivity and distribute my work to a very small community.
>
> Foxite is a great resource for keeping me out of trouble, but someday I know I'll need to hire an expert to make my applications more robust and networkable.
>
> So I direct my query to you VFP consultants in Foxite land: What are the common coding practices that newbies make that I should avoid to make your consulting life easier?
>
> Three things I've heard on Foxite so far
>
> 1. Keep public variables to a minimum
> 2. Use Hungarian notation
> 3. Create your own subclasses of the VFP base classes
> 4. . .
> 5. . .
>
> Are there certain coding practices that make you want to tear your hair out?
>
> Dan Baker
> Effort of the Poconos, PA, USA

One point not so far mentioned:

If you do serious development in VFP, very early on you must develop your own or use a commercial framework.
I use my own framework and stick to it religiously. The reason is that in most languages there is always more than one way "to skin the cat"

Take for instance getting data from a SQL table:
SQLEXEC, Views or CA - whichever method you use, you must do it using a framework, especially using Cursor Adapters. There are so many settings in a CA, properties as well as DBSETPROP that if you don't then you have no consistent way to debug or fix anything.

So, soon after you subclass your base classes, you must begin to develop and use a framework and make sure you stick to it, even if it means extra code.

Second point:
Try and make your framework data driven as far as possible.
Lets say you have this select statement "select fname, lname from client" and this is used all over your forms. If you hard code it into all the forms, then if anything changes where you need to change this select statement, you will have to change it all over the place. But if it was stored in a table then you just need to change it in 1 place.

Third Point
Never use hard coded paths - these are when you have code like this in your prgs or forms:
cDatapath = "c:\mydata\myprojectdata"

This should be stored in an external config file - I use a vfp table for this.

Final Point
Recently I came across this problem I had. I had business rules in a class but the rules used the VFP function DATE() to calculate different date ranges for the rules. We had a need to update the application and insert a "Disaster Recovery" mode wherein the date was to be set 2 to 5 days backwards. This was in the event that a site went down and could not use the computers. They would revert to a manual paper process for all functions, including cash. Now these paper records would only be entered into the database about 2 to 3 days later but had to reflect the original date they had been created not the current system date.

Out went all the DATE() code because DATE() in this case could be yesterday or the day before for the purpose of calculating the business rules and date ranges allowed. My solution was to create a form variable called - curdate. This was set in the INIT and then wherever I had used DATE() I replaced it with ThisForm.curdate.
So now I just need to change the logic in one place and assign a date to the form var and not all over the form.

HTH


Bernard

** If you see someone without a smile, give em one of yours :) **