Object Naming

We do have layout objects covered, although not in an obvious subsection since it's somewhat hidden on Layout naming. We can also discuss the merits of the current spec there too.

Per discussions in other comment threads, most all of the early adopters have agreed that we're not in favor of cryptic naming conventions that use shorthand keys, such as T for text or tab, etc. This is because you get into situations where you're using something like X to mean text which is completely obscure to anyone who doesn't know your database.

The standards here will serve as a guide for anyone who claims their solution has been coded against them. The primary objective is "readable" code - without an explicit requirement to read this documentation before hand. Therefore, your proposal would be translated to the full words for element names with lowerCamelCase to follow suit with $variableNames and fieldNames.

As has been stated before (in other places on this wiki), using a shorthand version of the longer standards documented here are certainly possible within any single developer environment. If you're the only developer on a project and you never intend to have anyone ever look at your code then there's no need to follow the standards here.

The truth of the situation, however, is that all software (in normal use) enters maintenance and that's when someone else may be looking at your code.

Trust me, I'm not trying to bully the use of full words over single letters or abbreviations. I love to develop quickly (or lazily as I often call myself when coding in shorthand) I've just found that it's extremely comforting to head into a solution and be able to "read" it rather than "decipher" it.

I'll leave the proposal here so others can chime in publicly, but if anyone has feedback about object naming then please leave comments on the page referenced above.

Because of FileMaker's limited viewing space in the Inspector for things like object names and value lists, I like the idea of using shorter names.

I used to be very verbose in my naming. For example, I used to name a relationship something like workorders_WorkOrderLineItems_Inventory_by_ItemID_is_Active. where 'workorders', 'WorkOrderLineItems' and 'Inventory are tables, and 'ItemID' and 'Active'  were fields on one side of a mufti-predicate relationship. That becomes WAY too much typing and as the solution grows, the details are helpful but the length of the string became painful to work with.

Now, I use considerably shorter names for everything starting with tables and the same relationship would be wo_WOLIF_Inv_ItemID_is_Active - In this case about 1/2 the length.

When you apply a hierarchical structure to object naming (which I feel is helpful at least and necessary at best), the small size of Object Name window in the Inspector is a real hindrance. I think that the short amount of time it would take a new person to identify that "P" is for portals is a fair trade-off as compared to the time to click in the window every time to see the full object name.

Three exceptions I would make to the original suggestion above though:

B: - for taBs

T: - for Text objects

R: - for containeRs

This more closely follows the shortcuts for selecting a field type upon field creation and thus gives a foundation for the naming.

 - BTW Matt, great idea to do this site and great job overall! I feel the FileMaker community really needs this type of guidance and these discussions. I wish you would take a couple seconds to mention this and give the URL in all your videos to really drive more discussion here. - Thanks!!!

Jeff Duck