In a recent discussion at the FileMaker Community a question was asked about why a FileMaker developer would choose NOT to use SQL-friendly field names. It's an important question that I believe many FileMaker developers often answer incorrectly. Here's a bit about how my view of naming conventions has changed over time.

For reference, a SQL-friendly field name in FileMaker would be a name that:

starts with a letter
contains only letters, numbers, and underscore characters
is not a reserved word (an evolving list of over 200 words including DATE, FIRST, FROM, VALUE, ZONE, etc.)

Developers also often adopt naming conventions that use PascalCase, camelCase, or a variety of prefixes and suffixes to indicate properties of the field or alter the sort order of fields.

I was once in the camp that thought it was a best practice to always use these kinds of naming conventions to optimize developer productivity. I come from a computer science background with experience in dozens of different languages, each with its own arcane naming rules. Some of those languages were created when every byte was precious...many computers had just a few kilobytes of memory, data transfer rates were measured in bits per second, and programs and data were stored on punched cards or magnetic tape. I started using some amalgamation of the various rules I knew when I began using FileMaker in 1986. Over the years, my naming conventions evolved modestly as the FileMaker platform changed and I was exposed to other developers' code.

The post FileMaker naming conventions appeared first on FileMaker Development Company.

View the full article