>>Actually, I think this is a waste of time in xBase too. It makes sense with variables because xBase is weakly typed (meaning you can put any value into any variable), so a naming convention tells the developer what data type is expected in a variable. However, fields in tables are strongly typed, so there's no need to use a naming convention to tell you the expected data type; just look at the table structure.
>>
>>My 2 cents (and I'm guessing I'll hear some opposing opinions <g>).
>
>I would argue strongly in favour of some form of naming convention.
>
>We have a VFP application which can use VFP, Oracle or SQL Server as a back-end.
>
>One of the fields was called Percent - this seemed ok in VFP or Oracle but caused problems in SQL Server [apparently because it is a reserved word]. Queries to the the back-end including this field caused syntax errors.
>
>I would argue that to use no naming convention, you would have to be sure not to use reserved words [both in VFP and the back-end]. Your choice of field/table names would also have to be governed by reserved words in future versions of the backend.
>Matt.

---

Matt,
I agree 100%, I've worked with more than 14 clients since 93 (when I went freelance) and almost all employ data type naming conventions on all fields irrespective of platform - Dbf, Sybase, Oracle, SQL Server and (currently) DB2.

Occasionally I will come across exceptions - the worst are of course the use of key words and at the top of the list of piss-poor is "date" - a data type that stands out the most from all the others (excepting maybe memo's). Invariably I find "date" being used in property, variable and fields names, where it is obvious that the developer lacked any kind of linguistic skill and/or the clarity of thought to describe the entity they were dealing with!

Arguments that data type should not be included in the field name because the User might encounter them are tenuous to say the least - use the caption option in the dbc instead.

And what does the following mean: "The other rule we have is to always use long field names, so that a field's contents can be adequately described for not only users, but any legacy inheritors".
- "Legacy inheritors" - sounds a tad contrived.

I agree (but only in part) with Mike Heland when he says that including too much superfluous detail can waste valuable naming space. When tables are freestanding and names are restricted to just 10 characters, I try to avoid the use of underscore, but the value of that one letter at the front is more than worth the price!

One comment posted else where in this thread suggests that developers should rely on Display Structure (presumably into documentation) - nice if:
- You are only working with a few (small) tables.
- Have a lot of screen real estate to play with.
- Or you enjoy having your nose buried in the documentation, if there is any, and if it is actually readable, and you can be sure that it is kept up to date, and ....

Personally I find it more useful to step through the code and for the code to contain all that I need (i.e. meaningful names and comments).

One thing that surprises me is how people that I took to be experienced and well informed do not see the value of indicating data type in field names. When it comes to indicating data type, why should field names be any less appropriate than variables (and in my case properties)?

This subject looks like an ideal candidate for a survey:
Q 1: Which of the following do you think should include a letter indicating data type:
- Variable names.
- Properties.
- Field Names.
Q 2: How many years experience do you have? This would be good if it could show how much of the experience was associated with looking after either legacy systems or systems written by someone else. Developers who are forever working on green field (AKA blue sky) projects, and never get involved in supporting those systems have opinions (in my opinion) that are borderline worthless. Personally I would like to see a complex heuristic here, that applied weighting to the response based also on the complexity, size and nature of the systems. Lets face it, how much value do you attach to the opinions of a developer that has only three years experience working for Mum & Dad sized businesses (Mom & Pop in the U.S.)

Regards to all.