Development Convention for Utility fields question

[Rich S]

Howdy, all:

I decided to wise up and start using the FM Development Conventions guide since I want my solutions to be held to a standard other than my own creative one.

The problem is that on page 23 the guide discusses using zz__FieldName__(storage)(type)(repetition) for Utility fields: other than the terse description of them on page 19, what are some examples of Utility fields (where I would use the zz__ nomenclature)? By the description on page 19, it sounds like anything other than a field an end user pops data into would fall into The Utility Zone, but that doesn't sound quite right.

TIA for your help!

Rich

[Vaughan]

I decided to wise up and start using the FM Development Conventions guide since I want my solutions to be held to a standard...

The great things about standards is, if you can't find one you like you can always make up your own.

There is absolutely no reason to adopt such a naming convention for FMP databases. I've seen systems where table names are prefixed tb_xxxx and custom functions are prefixed cf_xxxx. Such conventions are only necessary when a solution consists of thousands of loose text files in a directory and there is no other way to tell them apart.

IMHO the only convention is to be consistent and avoid spaces in names because one day the file will be the back end for a web site. Whether field names use underscore or CamelCase is completely decorative, and even naming inconsistency within a system won't actually BREAK anything.

[comment]

Couldn't agree more. Field names are for people - they should not look like a course in cryptography. And "zz" is a prefix for a band.

[RodSierra]

Not to pile on here, but I also could not agree more. Best recommendation I can give is to stay consistent and use labels that make sense to you. Camel Code...learned a new term today, been using it since my early days in controller coding, ButNeverHeardItCalledThat!

[LaRetta]

Hi Rich,

I am in agreement with the others that naming can get quite convoluted unnecessarily. I think it helps to have field names end with _x if the field index must remain on or ending with _r if it is a repetition. Field names themselves should clearly tell us whether they are number or date so I don't add the data type at the end unless it breaks with normalcy (usually legacy systems) that cannot be immediately corrected.

zz_ appears because the theory is that the fields will sort with the 'developer' data at the end so Users, if picking from field names, are less likely to see or select them. Problem is ... many of the dialogs where a User would select a field name are not alphabetized anyway (instead they are provided in creation or scrambled order) so it does little good.

Having the field begin with the table name is (usually) overkill. And the problem with these extra characters is 1) field names become so long that they are unreadable in many of the pop-up selection dialogs such as export and 2) Users hate these extra characters. If ContactID is in the Contacts table then it is the primary key. If it is in the Invoice table then it is the foreign key so I see no need in beginning them with pk and fk either.

Many of these naming attempts result because FileMaker lacks proper Developer tools, such as hover over any field name in layout mode and see the data type, calculation and storage. And FM should allow us to assign an alias (at the field level) like we currently can assign a comment. They also need to allow the Developer control over what fields a User can select from (for exports etc). Until then, naming conventions will never fully suit everyone's needs.

It is like a grocery store ... take what you need and leave the rest.

[Vaughan]

I think it helps to have field names end with _x if the field index must remain on

FileMaker will index a field if it's needed, automatically, unless the indexing has been explicitly turned off. But who'd do that?

There is also the false impression that the naming convention determines the field characteristics: that naming a field xxxx_g will "make" it global. I've seen that a couple of times.

BTW great to see you around again LaRetta.

[bcooney]

We started off about 6 yrs ago (when we switched to FM7) using the FM Dev conventions. However, right away we felt that many of the prefixes/suffixes were overkill. For what it's worth, we've ended up naming fields so that they sort together (bcs we always sort fields alphabetically). The fallout is, Addr_Street, Addr_City, etc., Name_First, Name_Last, etc. We always use __kP_PrimaryKeyID and _kF_ForeignKeyID, dsp_DisplayField and zz_CreatedDT, zz_CreatedBy, g_GlobalField, p_PreferenceField. When you work as a team, conventions (especially for TOs) are invaluable, and save time bcs the fields eventually name themselves!

[LaRetta]

FileMaker will index a field if it's needed, automatically, unless the indexing has been explicitly turned off. But who'd do that?

I would. Here are a few links:

Why remove index?

FileMaker Pro 9 Missing Manual

When we add fields, sometimes we forget to consider the storage options; whether minimal and uncheck 'automatic' (for relational keys) or whether to index at all. If we don't identify the fields which SHOULD remain indexed, we could inadvertently clean up and turn off an index for a field used for a value list or secondary filter key and FM cannot warn us when we leave definitions. Of course if the field ends with ID we know to leave index on but it could bite us elsewhere.

And thank you for making me feel welcome again, Vaughan. I really appreciate it.

Modified to add another link and remove some of my chatter since the links cover the points better than I could anyway. :D

[comment]

I prefix (or suffix) fields that are calculations, global, summary or repeating - because I need to see that when selecting a field for a calculation, export, matchfield, etc. I am not sure field indexing falls in this category - perhaps the field's comment would be a better suited location for this?

we've ended up naming fields so that they sort together

IMHO, it takes less time to sort the fields manually - and the results are much better.

[LaRetta]

I am not sure field indexing falls in this category - perhaps the field's comment would be a better suited location for this?

I didn't really think about it before; you are right. A highly respected colleague of mine (J) uses it so I just adopted it. Knowing is important but it doesn't have to tag the field name itself! Thank you, Michael.

[TheTominator]

what are some examples of Utility fields (where I would use the zz__ nomenclature)? By the description on page 19, it sounds like anything other than a field an end user pops data into would fall into The Utility Zone

In this convention I define "utility fields" using the zz__ nomenclature to be fields that would be of no interest to the end user. They shouldn't be useful as a sort key, mapping an import/export field, or in a calculation.

The zz__ fields are usually present solely to support the user interface and are not part of the data model.

The "zz__" prefix is a best effort to make these fields invisible by making them appear at the end of the alpha sort order when possible. End users are exposed to the actual field names in the Sort dialog, the Export and Import dialogs, and the Replace Field Contents... (with calculated result) dialog. Even if the fields don't present themselves alphabetically, you can tell your users that all of the zz__ fields can be ignored.