> > 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 more advise: when dealing with tables/cursors - try to use fully qualified fields' names, that is use the alias names with them, i.e.
>
>

m.CustAddr = CUSTOMERS.Address1 + CUSTOMERS.Address2
> && instead of
> SELECT CUSTOMERS
> m.CustAddr = Address1 + Address2

> First off, it would save you a line of code (no need to SELECT CUSTOMERS).
> Second, it makes your code independent of the currently selected work area.
>
> Moreover, I would recommend using the explicit reference to the pertained table's alias every time, everywhere! For instance:
>
>

REPLACE CUSTOMERS.Inception WITH DATE(), ;
>         CUSTOMERS.Category WITH "New" IN CUSTOMERS

> this would save you - and VFP - from a lot of confusions (and therefore - program errors) over what field belong to what table, especially if you have identical field names in different tables (which does happen).

Hi Ilya

In the case of replace I usually do the following...

REPLACE ;
	INCEPTION WITH DATE(), ;
	Category WITH "New" ;
	IN Customers 

That's because it's very easy to type and, to me, easy to read.

The only time I add alias references is ...

SET RELATION TO SOMEFIELD INTO TABLE2
REPLACE ;
	Inception with TABLE2.SomeField, ;
	TABLE2.Category with "New" ;
	IN Customers

This way TABLE2 stands out very strongly as something atypical.

I try to avoid adding table references to my SQL commands unless I have no choice.

Mike Yearwood
www.foxridgesoftware.com
President: Toronto Ontario FoxPro User's Group