Naming Conventions / Experiences

Lounge (Discussions)
1

had a lot of discussions about FileMaker Naming Konventions

So, i post mines, for the case, it may help someone.

Background
Since long time i work together with a group that had FileMaker as customer. So, we had a good insight how good FileMaker programmers working. We are ruby on rails programmers. RoR is a huge community which has the strict rule "Convention over configuration", that is loved and used by the whole communnity and is one reason for the success of that framework. Ruby, in turn, is derived from Linux, Perl, Phython. Principle from the founder, "Mats", is: The code has to be nice. If the developer loves the code, the resulting Apps will be better ones. From that, we can learn. So, the idea is derived from there, and adjusted to good practice in FileMaker.

The more you are speaking the same language like other developers and is compatible with other programming languages the longer you and your customers will be happy

Rules in General

  • Less is more
  • Self-explaining (no special chars (exceptions below), and no ÄäÜüÖö).
    At the point you have to build interfaces to other systems, special chars can cause problems. At the point a other developer should understand your system, he may not understand what is meant. He will rebuild it. We have to think as community.
  • Dot separates one sentence from another in human langugage and one instance from another in object-orientated programming languages (Dot-Notation). So, dot is the separator for separating tables in relationships graph.
  • Underscore is common in SQL field- and table names and will never cause problems in communication with other languages. Words, beginning with underscore means: Sub (Sub-Script / Background-Layout / variables). Compare: partials in rails.
  • Decide good how many you want to leave comments or making documentation, because its likely that nobody reads that. FileMaker is self-explaining. Dont make it complicated! But, the necessary has to be written.
  • Shortcuts for table-names if you want are ok because anyone can derive the sense, but in case of doubt: write it out.
  • use lowercase in general. use uppercase conscius and squarely where you want mark something, and that is in Filemaker always the same: the huge select-lists where you have to select the table-occurrences. You can save time if you see on the first look what you want to select

Table Occurrences (TO)

  • Strict anchor-boje system, from left to right
  • In capitals: is the part, which names the table, laying behind
  • Dot: separates table from table
  • Underscore: means option _cr => allow record creation; _del_sort => delete, sort

Self-join
pers.PERS_zip => persons which having the same zip code

PERS => is "root" => THAT is the only one, which has a Layout behind.

Complex
people.offer_current_year.ORDERS_cr_sort
=> Originated from people, over offers (from the current year), to orders (allow creation and sorted)

Benefit
In the select lists your see always, from left, from where it starts, and, on the capitals, you see quickly which table is laying behind

Field-Names

  • CamelCase or under_score or mix_of_BothIsAllowed => depends on the case and feel free
  • No special chars, no space in field names (only exception: underscore)
  • Global Fields: my_field_G / g_my_field
  • Calculation fields and self-calculating text/number fields: c_result / result_C => depends on the case, but most times i use the praefix, less the suffix

Layout Folder Structure

  • TAB => Folder for Layouts, that are internally (not visible by user)
    here every Table has one Layout in table-view.
    Scripts can use this layouts, and the developer can easily switch the browsed columns => gread help on debugging!
    All layout names here starting with underscore, because they all are used only internally or in the background
  • SCRIPT
    Layouts special for scripts, ONLY if there are script steps that requiering visible fields, like copy e.g.
  • API
    All Layouts which are used from externally have to reside in a explicit named folder
  • Working Layouts
    Good idea may be to name them based on the table (invoice => all layouts regarded to invoicing)

Script Folder Scruture

  • START => all script that are related to start routine
  • DEV => scripts for the developer
  • SYSTEM => Scripts that are used by the whole system (in linux / ruby that would be the lib (libraries) folder)
  • SERVER => Script for server-side-scripts => but, i learned: If you have no script running on server, you may never have to restart the server
  • All the other Sript folders: bee free, but its a good idea to name them like the table (rails has a similar way)

Script naming

  • _my_sub_script => sarting with underscore => subscript, which is used by other script

Plural / Singlular

Table occurrences

  • customers.INVOICES => one to many => plural (root (left tag, "customers") is always plural, because it has to be the same in all which are originated to "customers" (anchor-boje))
  • invoices.CUSTOMER => many to one => singular

Layouts

  • people => is a list view
  • person=> is a single view

So easy :slight_smile:

Script Parameters

For better making reusable functions, sub-script with dynamic parameters, and being more flexible in variables, i wrote some CFs: Json_ScriptParameter_CF.fmp12.

  • kv_PushParams: having a script-parameter like "$date=1.3.2021$name=john$dialog=1", and, in the first line of the script, you just make kv_pushParams. Then you can see this three variables, set with theyr values, in the data viewer. Its a function i use since many years in every second script. Its tested with special-chars and stable, you can rely on it. Its derived from that what is standard in other languages: calling script with multiple parameters. So, its easier to build sub-scripts that are flexible and reusable.

Best Regards,
Chris

6 Likes
2

I’ve been researching naming conventions and found some good advice on the Community forum:

Mike_Mitchell wrote:

The most important part of a naming convention is to use one.

The second most important part of a naming convention is that it be consistent.

The third most important part of a naming convention is that it be easy to read and understand (you don't want to spend time trying to figure out what the name means; slows you down).

As I update my files, I am trying to enforce consistency; however, I am treading carefully to ensure I don’t break anything.

2 Likes
3

Thanks Steve, good post!

To Mike Mitchell i would add:

Search for a convention that works in all cases and is logically and is nice.
From that, you will never have to think about it: You will use it.

Clear: maintaining existing systems is another case: renaming can destroy functions if there are Functions used that are based on the name, like:

  • xml-api
  • rest-api
  • sql-functions
  • get-field-by-name
  • evaluate-function
3 Likes