14 Replies Latest reply on Mar 30, 2012 10:14 AM by Stephen Huston

    Naming Conventions

    jbrown

      Hi all.

      I'm new to this forum. Ive taught myself FM over the past three years and am a decent developer. I work for a small charter school district in Colorado. I have designed an information system for one school, and am expanding it to three schools.

      You can read more about me in my profile. I'm glad to be on this network. I'm excited to be able to post questions.


      My first question: What are the typical naming conventions for fields, tables, primary keys, foriegn keys, etc? I am starting to consult with a friend of mine who's on here somewhere, and he told me some of the conventions. What are the other ones/ all of them?

       

      Thanks.

      I'm sure i'll have thousands more questions if that's alright.

        • 1. Re: Naming Conventions
          rjakes

          help.filemaker.com/app/answers/detail/a_id/6820/kw/Development Standards/

           

          http://help.filemaker.com/ci/fattach/get/9198/

           

          A bit long in the tooth, but a good start.

          • 2. Re: Naming Conventions
            beverly

            Jeremy, You will get several answers and methods. Choose one that you like and stay consistent. But above all, remember that IF you ever EVER want to connect FileMaker with another application (including web), you will do well to use ONLY alpha-numeric characters and underscore ("_") in every name you create (scripts, tables and fields, layouts, value lists, custom functions, relationships, etc. Just words from someone that's been there and done that...

             

            Beverly

            1 of 1 people found this helpful
            • 3. Re: Naming Conventions
              jbante

              Different developers each use different conventions. Most companies have their own conventions they stick to internally, but there's no one authoritative set of conventions all developers stick to. You can see another set of conventions at FileMakerStandards.org.

              1 of 1 people found this helpful
              • 4. Re: Naming Conventions
                beverly

                j! love this site. the caveat on the overview page expresses my concerns for using the conventions that are on it. I know several people have put a great deal of time into this. I have put a great deal of time having to work-around or change these "errors" because I spend a great deal of time connecting Filemaker to others (to and from).

                 

                 

                Special note

                These coding standards are based on developing a FileMaker solution for use within the FileMaker client/server architecture. They prioritize considerations of that architecture over compatibility or ease of use for other FileMaker supported connectivity methods including Instant Web Publishing, Custom Web Publishing, FileMaker PHP API or FileMaker Go. You will see the use of various ASCII characters beyond numbers and letters, such as the percent sign (%) and tilde (~), within these specifications that are known to be discouraged in use with other FileMaker connectivity methods. It is assumed that, as a developer, you are using FileMaker Pro Advanced for developing your FileMaker solutions.

                Please visit this page for reference on URL character encoding issues from the IETF and how that may impact alternative connectivity methods to a FileMaker solution.

                 

                 

                buyer beware!

                Beverly

                • 5. Re: Naming Conventions
                  jbante

                  In my own use of the standards, my main concerns for connectivity with other solutions are the naming of tables, table occurrences, and fields. Tables and fields as described are already compatible with almost everything. I just replace the "»" character and surrounding spaces in table occurrence names with double underscores "__", and everything's peachy. The FileMakerStandards.org page on table occurrence naming mentions this as an acceptable alternative.

                   

                  Further, if anyone has suggestions for edits to the conventions that would improve compatibility with other tools, I encourage them to leave a comment on the website with any ideas.

                  • 6. Re: Naming Conventions
                    jbrown

                    Thanks all for your advice. In the last few days of my spring break I'll go through every table and field and do some renaming.

                     

                    Thanks

                     

                    Sent from my iPhone

                    • 7. Re: Naming Conventions
                      Malcolm

                      Thanks all for your advice. In the last few days of my spring break I'll go through every table and field and do some renaming.

                       

                      Changing names breaks things!

                       

                      I advise against changing names in an existing application. There is too much to go wrong and too little to gain.

                       

                      1. imports based on matching names will break

                      2. calculations often require names to be hard coded, eg, getValueListItems( filename, value list )

                      3. your own calculations may used hard-coding, eg, getField( get(layoutTableName & "::_id kp")

                      4. your scripts may use hard coded names, ie, go to object['start']

                      5. complementary systems, such as appleScripts, batch scripts, shell scripts, web sites, will all use hard-coded names.

                       

                       

                       

                      Malcolm

                      • 8. Re: Naming Conventions
                        rjakes

                        >> 1. imports based on matching names will break

                         

                        Actually, not. Though it would be preferrable (to me) if it did.

                         

                        As for the others, changes to fields names can be confirmed safe with a DDR and BaseElements. Better to fix anything that will make interaction with external systems/code difficult.

                        • 9. Re: Naming Conventions
                          jbrown

                          At this point I have no external code or reoccurring imports that could be messed up.

                           

                          Ive never seen, when I have changed a name here or there, the calculations being messed up. I thought that filemaker changes those names in the script/calculation.

                           

                          But I will be careful.

                           

                           

                          From: Roger Jacques <noreply@filemaker.com<mailto:noreply@filemaker.com>>

                          Reply-To: "fmi-832004196-mk3-2-1m8t@fmdev.filemaker.com<mailto:fmi-832004196-mk3-2-1m8t@fmdev.filemaker.com>" <fmi-832004196-mk3-2-1m8t@fmdev.filemaker.com<mailto:fmi-832004196-mk3-2-1m8t@fmdev.filemaker.com>>

                          Date: Thu, 29 Mar 2012 17:39:23 -0600

                          To: Jeremy brown <jbrown@kippcolorado.org<mailto:jbrown@kippcolorado.org>>

                          Subject: Re: Naming Conventions

                           

                          http://www.filemaker.com/images/devrel/fmdev-logo.png<https://fmdev.filemaker.com/index.jspa>

                          created by Roger Jacques<https://fmdev.filemaker.com/people/rjakes> in General - View the full discussion<https://fmdev.filemaker.com/message/75485#75485

                          • 10. Re: Naming Conventions
                            Malcolm

                            Ive never seen, when I have changed a name here or there, the calculations being messed up. I thought that filemaker changes those names in the script/calculation.

                             

                            Filemaker looks after most name changes automatically because it uses IDs under the hood. The issues that I raised cause problems because the name is used and not the ID.

                             

                            malcolm

                            • 11. Re: Naming Conventions
                              Vaughan

                              In another thread somebody is using Evaluate() with a long expressions in it. Field names in quoted text will not be updated if they are changed in define fields, and the expressions will subsequently break.

                              • 12. Re: Naming Conventions
                                comment

                                Vaughan wrote:

                                 

                                Field names in quoted text will not be updated

                                 

                                That's true, and so are the other cases that Malcolm mentioned. However, the solution is not to freeze the names as they are in fear you'll break something, but rather avoid hard-coding whenever possible and document it when not.

                                • 13. Re: Naming Conventions
                                  Stephen Huston

                                  I agree with everything offered above, and would add these items to consider:

                                   

                                  Yes, hard-coded text references to field names, including Evaluate trigger-field lists, will break with field renaming, even though FM handles direct references to field names which are not text-quoted just fine.

                                   

                                  However, at least as important as having a naming convention is commenting your fields in the define database/define fields screen. This allows you to use plain words to fully describe the intent of the field.

                                   

                                  You indicated you are fairly new to FileMaker, so image what will happen when you discover that something you haven't looked at in 6 years needs revision or troubleshooting! If you have to go digging thru everywhere the field is used to figure out why it is setup that way, you will find it's just as hard to debug your own stuff after a long time as to debug stuff written by someone else that you've never even see before. Fully commenting out field definitions in plain language helps avoid that pitfall.

                                   

                                  I personally prefer using field names that are not heavy on complex conventions, but fairly informative as read. I use a lot of "camel-case" (ie dateOfDelivery) or underscored (ie date_of_delivery) rather than stuff that is based on complex conventions (ie cs_d_delivery to indicate a stored calculation returning the date of delivery). For me, picking the field from a list when placing a new file on a layout  is just faster if I can make sense of the name instantly.

                                   

                                  Keep in mind that you will change your naming convention over time. That's what we get for learning how to do things better as we go along. But it also means that a naming convention that you know inside-out today might not be transparent to you 5 years from now.

                                   

                                  So my recommendation is: keep it simple.

                                  • 14. Re: Naming Conventions
                                    jbrown

                                    Thanks all.

                                    I'm listening to every piece of information. The theme, i'm seeing is that I need to:

                                         1. pick a convention and stick with it

                                         2. document my structure

                                         3. LeaveOutSpaces

                                         4. keep_it_simple.

                                     

                                    Thanks