Naming Conventions

[sal88]

Hi, are there any naming conventions that should be adhered to in filemaker?

thanks

[Vaughan]

There is a development conventions white paper floating around somewhere (look on the FMI web site) with *suggestions* dressed-up as recommendations, but IMHO the only conventions that should be adhered to are:

1) be consistent

2) be clear and concise

3) don't use illegal or reserved names or characters (FMP warns you when it doesn't like a field name)

I'd rather fields were named for function (eg, "Name Last" or "Address Postal City" but others like names to reflect their type (eg, "txt_Name_Last" etc).

I'm sure others will disagree.

The great thing about development standards is that you can always make up your own if you don't find one you like.

[Fenton]

Here's the official, and long, FileMaker pdf on the subject. It is good, in that it does not enforce any one convention; it's more like Vaughan say, consistency is probably the most important.

http://www.filemaker.com/downloads/pdf/FMDev_ConvNov05.pdf

I imagine each of us has their own variations, either additions or subtractions from the conventions above. The most important thing is that you always can tell what something is from its name, and that it sorts alphabetically where you'd expect it to. This is most important for Table Occurrence names.

I would agree with Vaughan; I do not prefix my fields with something like "txt_"; because when I'm looking for the last name I'd first think of "name", not "txt". But I do prefix all calculations, usually these days with "z_c", which; 1. Sorts it to the bottom (out of kindness to the poor user who might want to export or something), and 2. Tells me it's a calculation.

But to each his own. There are pro's and cons to each variation. I've seen conventions where every ID was like:

id_pk_SerialID

id_fk_Client

which conveniently put all the IDs together.

Personally I think that the place where naming conventions are critical is the Table Occurrences (TO), and Table Occurrence Groups (TOG). I always use the anchor-buoy method, with TOGs on larger files, and always prefix each TO with its TOG abbreviation. I always, where possible, abbreviate the name of every TO the relationship passes thru. It can still be a little confusing, but at least it's explicit. I don't much believe in the "name it for what it does", as, 1. I often include the field(s), so I can tell from that, and 2. Many TOs are used for several things, and some are used for things that just cannot be put into words. This last point is glossed over in simple files, but in complex files...

[stanley]

Sal:

One thing to keep in mind when deciding on a naming convention is that the list of fields can grow quite large, and that one of the sorting options when defining fields is to sort alphabetically. Using a prefix can help you when you are digging for a calculation or global and you can't remember what it is called. From all the years of helping people on these boards, I can say that most folks seem to have their own conventions.

I use prefixes followed by an underscore:

kf_ = key field (serial number)

g_ = global field

t_ = text field

n_ = number field

d_ = date field

ts_ = timestamp field

c_ = calculation field

s_ = summary field

OBS_ = obsolete field, used to mark stuff that's out of use and should eventually be deleted.

Anyway, you can roll your own, but there is, if I remember right, a fairly complete set of suggestions in the Best Practices white paper that Vaughn mentioned.

-Stanley

[sal88]

wow thanks for all your help!! how about field sizes? is it worth setting those?