>dDuedate why not DueDate?

why not just dDue?

>cCity, cSt, cZip, cPhone, cCell
>
>It's just a waste of a character.
>

Not really, you could use a numeric code for a city, I wouldn't, and I know I wouldn't, but there's no guarantee of that, and besides what if someone other than the author is reading the code, should he just assume things?.

>
>Does anyone ever do a Public anymore? If not why should I disclose that everything is local.


It's helped me give a variable the same name as a field for calculation purposes, with the difference of the scope specifier, and long gone are the days where I got my vars and fields mixed up.

>Now If a comapny set standards like table filed names have the first 2 digits defining the table they reference, that would be somthing I would agree with.
>
>SHordnum = Sales Header order #
>SDlineno = Sales Detail line #
>SDqtyord = Sales Detail Qyt ordered
>SD_ID = Sales header Primary Key
>SD_SHK = Key to Sales header
>SH_CUK = Key to customer table
>
>Now in a join my primary keys are unique in name and that is something that is usefull.
>
>Where in the example below:
>Sele Cust.iid, customer.cCompany, SOHeader.iid ..... ;
>from VES!Cust inner join VES!SOHEADER ;
>ON Cust.iid = SOheader.iid ;
>where ... ;
>This will always give iid_a, iid_b in a return set and it's a RPITA to adapt the rightful keys to the proper tables in a view.

I had a coworker who did that and I surely didn't like it, just knowing the table name is enough to me, I had to keep looking up field names while writing code, there's no telling how he'd abbreviate the table name.

I see it like property names, same properties have the exact same names in different classes and objects. It's just simpler to remember the name like that, IMO.

Also having the same name across tables has made it easier to write generic code in some classes. As far as SELECTS you can use the AS clause to give the field a distinctive name.