Naming conventions are a method for describing your information, fields, objects, tables, table occurrences, scripts and any other aspects of your FileMaker Pro solutions.
In this short (..ish) screencast I delve into the very basics of what naming conventions are, and more specifically, how you – as a beginner – should not worry about adopting a naming convention until you have evolved your development technique and style a little.
When you start out with your development it is often a case of what you should not do, rather than what you should do. Naming conventions falls into this category. If you only develop for yourself then this is less of an issue, but when you start to collaborate or do development work for others you need to bear in mind that others may not understand your naming logic.
Who’s This Article For?
This article is not for experienced developers, this really is for beginners.
The message I am conveying in this article and screencast is that new developers really should not worry about using naming conventions in the beginning. Naming conventions, to use a simile, are like when you first design your signature as a teenager. You change it and evolve it over a number of months until you end up with a signature that you want to keep.
Developing your naming convention is a little bit like this. You are better to settle on a naming convention/system before deploying it, then you’ll save an awful lot of backtracking to standardise all of those older files.
It’s a problem I’ve faced myself many times, and don’t care to do again any time soon. So better to develop your method first, but not deploy it until you feel comfortable with it and it logically makes sense. Bounce your method off your co-workers to see if they think it makes sense, or even other developers.
I’m not saying that you won’t continue to evolve your naming convention over a period of years, you will, but it won’t be wholesale changes – just minor adaptations here and there, and you can normally live with those without going back over old files until you do a meaningful update.
Write your method down, make a cheat-sheet or something similar with your convention on it so that others can learn it or follow it. Do I have a cheat-sheet? No, but I really should.
What Are The Naming Convention Rules for FileMaker Pro?
There are no rules, just apply common sense (you know, that thing which isn’t common at all..). You can take a look around many FileMaker Pro Developer websites, quite a few give instruction on naming conventions.
This is because it is always easier when they have to pick up your files. It just makes the orientation process shorter, of getting into the logic of your solution, this means less time and less cost, for you.
But, apart from the cost savings when using outside developers, which is only a part of the reason for using a naming convention, you should use one for the benefit of everyone in your own company. It doesn’t have to be elaborate, but it can be if you want to. Personally, I have seen some excellent ones around different sites. You have to weigh up what will work for you, and your group.
Don’t get too hung up on making sure you jump straight into using a naming convention just because a file you saw happened to use one. Make sure every change you make is for the betterment of your solution and your development style, not just for change’s sake.
I will be making some further tutorials on naming conventions shortly. Those tutorials will contain, mostly, the naming conventions from other developers that I admire and their conventions that I believe will help you logically construct better solutions.
Essentially, my advice is to use plain long descriptions to start with, then whittle back from there as you refine your own naming convention and then start to apply it in your development. If you plan to use web publishing via FileMaker IWP or CWP, then you would also be advised to avoid using spaces within your field names. As a matter of course, I remove all spaces from all titles/descriptions within FileMaker, fields, scripts, table occurrences – everything.
This screencast covers only fields and table naming conventions, but equally, your convention should include all of the other aspects such as table occurrences, scripts etc.
Naming Conventions With Scripts
For instance, with scripts, I use portable scripting wherever I possibly can. This is a topic that I will cover later. When I create a script that is portable I append the word “Anywhere” to the end of the script. I always know that the script is portable and that it can be re-used over and over within the solution and across other solutions. Here’s what it looks like:
Again, I always omit spaces from everywhere in file names, table names, field names – everywhere. You don’t have to do this, but if you ever want to start web publishing, it can be a problem. Different developers use different conventions, there are few topics that rouse a good squabble like naming conventions can.
Naming Conventions with Table Occurrences
Naming table occurrences is another area where you need to experiment with the best method to suit you. There are several ways in which to construct relationships. Ray Cologon of NightWing wrote an article about the different ways to structure FileMaker relationships, you should check out his site, which is simply brilliant.
Personally, I use a simple method of combining where the data is coming from, and what it is being related to. Such as the following example.
The above example shows a simple self-join relationship, on the left side, and a one-to-many relationship on the right, using native tables (root tables) to relate one to the other. Here I just use the base table, sometimes I see developers using TO’s for this – you do what suits you. (TO’s = Table Occurrences)
When I use a one-to-many, or a series of one-to-many relationships, such as in the image above, The first part of the TO name is the base table, and the second part is what it is being used for. Again, there are a number of ways to accomplish this, in larger solutions you might want to use something a little more flexible and less onerus on the part of naming conventions to get you through. But, in smaller solutions it is absolutely fine to use the method above, and it is a more natural method for developers early in their journey.
Screencast
Enjoy the screencast. All comments are welcome.
Play Screencast
About the Author: Darren Lunn is on a mission to help FileMaker beginners become competent FileMaker Pro developers. You can connect with Darren on Twitter
No related posts.
{ 2 comments… read them below or add one }
Hey Darren,
Nice! I don’t necessarily agree with everything you do, but it does all make sense. My naming conventions are pretty specific for my development style, so I certainly wouldn’t argue that they are any better.
One thing I often tell beginners is that it doesn’t matter so much what your conventions are, as long as you are working towards having some.
One of the places I got my first idea about naming conventions is from the “FileMaker Naming Standards and Conventions” document that you can find here: http://coresolutions.ca/custom-software/filemaker-resources
CoreSolutions were one of the first companies I came across (year ago!) that were talking about naming conventions.
Paul
Paul, Thanks for that great resource, I can’t believe I’ve been developing for over ten years and not seen that before! It’s a good document and full of pragmatic conventions. One of the best I ever saw was from Linear Blue in the UK, but unfortunately it’s no longer available on their site.
It’s kinda funny that most of us never really agree 100% with each others conventions, like I said in the article, nothing rouses a squabble quite like naming conventions. I purposely kept this article on the lean side.
I intend to do some more on the subject in future, in reality, there’s quite a bit more that I do that wasn’t shown here (like primary and foreign keys, multi-keys etc).
Thank you for taking time out to contribute, Paul.