> 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

Dan,

Off the top of my head (most likely because I have run into these recently.)

1 - Don't use indexes to order your data for presentation. Indexes should really only be used to optimize your application. If you want your report data sorted in a specific order, use a SELECT ... ORDER BY.

2 - When you issue a TABLEUPDATE() check the return value. How will you know if the update succeeded if you don't?

3 - Normalize your database and make sure that the database design is sound. You will create reams of very confusing code if your database design is not right. I ran into one database where the developer spent most of his time "working around" the database. If you think you are spending too much time designing the database - double it! This is the foundation upon which all of your apps will hang. If you get this right, your apps will be efficient, fast and easy to develop. If you get it wrong ...

4 - Comment your code - before you write the code. Start by developing your comments. This gives you a pseudo code basis and allows you to think about how you want to write that code.

5 - A method should do one thing and one thing only. If you need to do something else, create a new method.

6 - use descriptive names. There is nothing wrong with a name like ".ValidateAddressDataAgainstThePostalDatabase()". True, it is long, but it tells you exactly what that method does. This goes for field names too. I ran into a table where two of the fields were SN and FN. These fields should have been named Surname and FirstName.

I'll be interested in seeing other replies here.

Ken
You shall know the truth - and the truth shall set you free. (John 8:33)