Field Naming Revisited with Version 8

[Ted S]

Hello,

There has been a defacto standard for naming FileMaker fields for quite a while and now with the release of version 8 I wonder if this shouldn't be revisited.

It has always bothered me that the established standards recommended field naming conventions to benefit the database developer rather than the user. For instance "txtFirstName" for or "numInvoiceTotal" rather than the more natural "First Name" and "Invoice Total". These sometimes cryptic field names didn't matter much in the old days because the typical user didn't necessarily encounter the actual field name unless they did a manual export.

Now with version 8 having the ability to directly produce Excel spreadsheets complete with column headings that match the field names I wonder if this standard is due for reviewal.

I personally have gone against the standards for this exact reason for a lot of years now. I do however use an underscore between words to avoid problems sharing data with other database brands.

Thoughts?

[BrentHedden]

Many of the "prescribed" naming conventions seem to make little sense to me. Like "txtFirstName" - well, NO KIDDIN' it's a text field! I wouldn't expect to put 12/12/2005 as someone's first name.

Unless the field isn't obvious what it should contain, there's no reason to put "txt" or 'num' or whatever in front. Of course, the problem is defining what's "obvious".

Having a space inside a field name initself isn't bad. But, if it's being shared with other databases or the web, it's best to use an underscore to separate words. Or capitalize the first letter of each word - like FirstName.

The excel export thing isn't much different than Table View. I've created several reports that use this view. Since the column headings show the actual field names, some fieldnames are somewhat confusing. The easiest way to combat this is to create a simple calculated field that referes to the actual data field, and name this calc field something presentable. Then use these calc fields in the actual table view or excel sheet.

[Ender]

Hey Ted, Brent,

With the exception of key fields and globals, I try to use field names that are naturally readable, but also such that they group together nicely when in alphabetical order, like:

Address City

Address State

Address Street

Address Street Type

Address Zip

Date of Birth

Date of Employment

Name First

Name Last

Name Middle

My key fields and globals follow the CoreSolutions development standards. Key fields begin with zk_ and globals begin with zc_. This keeps them all grouped together at the bottom of the alphabetical field lists.

I'm not sure FM8 will change anything for me, as it's unlikely I'd give users the ability to choose their own export fields and I probably wouldn't export the key fields. The underscore between words thing is something that I've done in some files, but not all, as I'm not doing much web publishing yet.