# Naming Conventions / Experiences **URL:** \ **Category:** Lounge (Discussions)\ **Tags:** naming-conventions\ **Created:** [March 26, 2021, 6:20pm UTC](https://the.fmsoup.org/t/naming-conventions-experiences/1967 "2021-03-26T18:20:01Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![christian](https://avatars.discourse-cdn.com/v4/letter/c/b2d939/32.png) [@christian](https://the.fmsoup.org/u/christian)\ **Post date:** [March 26, 2021, 6:20pm UTC](https://the.fmsoup.org/t/naming-conventions-experiences/1967/1 "2021-03-26T18:20:01Z")
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 🙂 **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](https://ticket.sedlmair.ch/projects/filemaker-custom-functions/files). - **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 ---
**Author:** ![steverichter](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/steverichter/32/1022_2.png) [@steverichter](https://the.fmsoup.org/u/steverichter)\ **Post date:** [March 26, 2021, 11:45pm UTC](https://the.fmsoup.org/t/naming-conventions-experiences/1967/2 "2021-03-26T23:45:57Z")
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. ---
**Author:** ![christian](https://avatars.discourse-cdn.com/v4/letter/c/b2d939/32.png) [@christian](https://the.fmsoup.org/u/christian)\ **Post date:** [March 28, 2021, 9:05am UTC](https://the.fmsoup.org/t/naming-conventions-experiences/1967/3 "2021-03-28T09:05:08Z")
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