1 2 3 Previous Next 86 Replies Latest reply on Dec 6, 2016 2:29 PM by Benjamin Fehr

    Field naming standard/conventions


      Currently I'm doing a bit of 'gardening' on my database.


      As I've learnt filemaker while developing my solution I've noticed 'some' of inconsistencies within the tables.

      I have read up quiet a few different standards but I'm interested in what sort of standard / methodology you guys use.


      I want to clean up mainly Table Names, Field Name, ID fields, Calculation fields.


      Here is what most of my tables look like.


      standard table.png

        • 1. Re: Standard/Convetions
          Benjamin Fehr

          FileMaker Coding Standards might give you some inspiration:

          Naming Conventions - Coding Standards - FileMaker Coding Standards

          • 2. Re: Field naming standard/conventions

            Also, if you are interested in coding in any way, shape or form, this book is invaluable:


            Code Complete - Wikipedia

            • 3. Re: Field naming standard/conventions

              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).


              Beyond that, you're rapidly going to get into the realm of "I like it this way", where every developer has tastes and preferences. I'm personally not a big fan of a lot of what's out there in naming conventions; I find most of them awkward, counterintuitive and unnecessarily noisy. So use what you find easy to understand. And stick with it.

              2 of 2 people found this helpful
              • 4. Re: Field naming standard/conventions

                For an example could you put what you would have within your solutions i.e.


                Table Name

                Id Field

                Field Name


                Its just within my solution I have alot of ID fields inconsistent for example


                Id, CustomerId or Customer_ID and foreign keys Customer_IDFK.

                • 5. Re: Field naming standard/conventions

                  +1 to Mike.

                  Most important is dont use spaces because it unnecessarily complicates SQL and make data exchange with other systems painful

                  • 6. Re: Field naming standard/conventions

                    Here is an example:


                    Tables: UpperCamelCase, singular (Invoice)

                    Fields: lowerCamelCase (nameFirst); prefixes for derived data types: cSomeCalc, sSomeSummary

                    Keys: 'id' for the primary key, 'id_parentTable' for foreign keys


                    Layouts: UCC

                    Scripts: UCC, as a verb (CreateLineItemsForSelectedProducts)

                    Custom Functions, their parameters: UCC, lCC - eg ToggleElementInList ( anElement ; aList ) - following the form of the existing functions


                    As has been noted, try to find something that makes sense to you, and be consistent.


                    After that, it's a matter of taste. I used to have table names in plural (there are many instances), but found the code to be more readable if it is in singular (it models one entity):

                    Customer::cNameFull, LineItem::priceExtended ...

                    • 7. Re: Field naming standard/conventions

                      Yes I guess so.


                      I would be happier with more definition between the primary and foreign keys. I'm only thinking so that they get sorted to the top of each table when viewing by field name.

                      • 8. Re: Field naming standard/conventions

                        Do not make the mistake of prepending the underscore "_" before PK or FK fields. That may cause issues elsewhere. If you use lowercase "a" before, the sort will be good and the possible breakage solved.



                        (for example)


                        Sent from miPhone

                        1 of 1 people found this helpful
                        • 9. Re: Field naming standard/conventions

                          Having brief and uncomplicated names for the key fields outweighs for me any (perceived) disadvantage of them being not listed at the top. And they stick together anyway.


                          But hey, it's *your* convention so do as you please.

                          • 10. Re: Field naming standard/conventions
                            David Moyer

                            Hi all,

                            I winced a bit when I looked at the conventions Benjamin noted in post #1.  I'm curious as to how many developers adhere to that convention?

                            • 11. Re: Field naming standard/conventions

                              I personally have never found that useful. I know it's been a "thing" for a lot of years (because it puts the keys at the top of the TOs on the Graph). However, I find it horribly counterintuitive. It's also not as useful as you might think, simply because you wind up opening the relationship dialog in most cases anyway to set relationship properties. So what I do is just drag the fields from one TO to the other, regardless of whether they're the right fields. Then, when you open up the relationship dialog, you just reset the fields while you're setting the other parameters.


                              I prefer to identify the keys with lower camel case "tableNameID". This gives me a very easy way always to identify the key with the table to which it belongs. I use a lot of DRY scripting, and having the key field with a predictable name across all tables is way more useful to me than tagging them with which one is primary and which one is foreign. If the table name matches, it's primary. If not, it's foreign.


                              But as I said, every developer has preferences, and generally has reasons for those preferences. Use what works for you.

                              • 12. Re: Field naming standard/conventions

                                I know they exist, that's it.


                                What about them qualifies as winceworthy?

                                • 13. Re: Field naming standard/conventions

                                  About the only thing I use from that convention is lower camel case. Not crazy about most of the rest of it.

                                  • 14. Re: Field naming standard/conventions

                                    One of my biggest gripes is the custom sort on field names. While that sounds great if you're the one doing the sorting, it royally stinks if you're trying to come in behind someone else. I'm in the middle of a rebuild on a large system where they used the custom sorting, and it took me forever to get a grasp on what fields were where. If they're sorted alphabetically, it's really easy to find them.


                                    One of the purposes for a naming convention is to make it easier not only on us, but on the poor slob who has to come in behind you. Having just dealt with that issue, I cringe at the custom field sort.


                                    Also not crazy about the ALL CAPS with underscores for global fields. Ew. Hard to read, hard to type. (I HATE underscores with a hot hot hate.) And I've already discussed the naming of keys. I just prefer them to have the same name across all tables.

                                    1 2 3 Previous Next