There are a few reasons for not using spaces, e.g. they make sintax more complicated in the CWP, FQL and ODBC.
There is no single widely accepted standard for a simple reason - every developer uses their own. On the other hand, I think FileMaker Standards made a good effort, so if you looking for a standard, why not to use them?
I suggest conforming to the strictest standard your entities could ever come in contact with (as mentioned by nicolai).
These entities will more likely be fields than scripts or, say, Custom Functions, but why carry the extra mental burden of using one “standard” here and another one there? (As the old adage goes: “The nice thing about standards is that there are so many of them.”)
Compare the Filemaker Standards document with the rules for class/variable/function/method naming in most modern programming languages, and note that they're very similar (and, IMO, quite reasonable without compromising readability).
Something has changed since the "FileMaker Development Conventions" were published in 2005.
Is that a statement or a question?
I believe the standards to which nicolai is referring are these ones at filemakerstandards.org. This group has formulated standards which prioritize highly readable code. I, too, think they are an excellent set of conventions.
As I read the FileMaker Development Conventions (FDC), it appears to say that spaces should not be used in the naming of scripts. I say "something has changed" because FileMaker's own starter solutions do not now follow these guidelines.
Following the logic snake down the hole, I had wondered whether RC Consulting's use of parentheses was also now acceptable to use. Personally I prefer the use of parentheses and the numbering of scripts, (makes it easier to reference and find) but if there could be conflicts with this naming convention down the road, I will stick with the safer naming conventions.
Thanks for the help.
The reason for recommending against the use of spaces or parentheses in web deployments is they aren't URL-friendly. They can be URL-encoded to solve the problem.
Or, you can just avoid using them altogether if you expect to be executing the script via the URL Protocol.
As others have said, there is no hard-and-fast "standard". There is no governing body. There is no Authority Having Jurisdiction. There are no fines for noncompliance. There are only recommendations, and consequences for poor practice.
A convention is just that: a (more or less) widely agreed-upon set of rules, usually devised by a gremium.
Think of HTML and browsers; there is a standard, and then there are implementations …
Who knows if the developers who crafted the Starter Solutions ever read that document. I regard this as an attempt by FMI to bring lightness into the dark of “no standard at all”; it didn't even have to be good as long as it raised the awareness for this topic, which I guess it succeeded in.
Following the logic snake down the hole, I had wondered whether RC Consulting's use of parentheses was also now acceptable to use.
Obviously, it is acceptable to them; make of that what you will.
Personally I prefer the use of parentheses and the numbering of scripts, (makes it easier to reference and find) but if there could be conflicts with this naming convention down the road, I will stick with the safer naming conventions.
Which I think is a good idea.
I'd regard these conventions as guidelines – if you implement them with (say) lowerCamelCase, UpperCamelCase (OrBoth), creepy_crawly_case, or your own invention, is up to your own taste and aesthetics …
There is no Authority Having Jurisdiction.
The compiler / parser / interpreter / calculationEngine you're targeting at this very moment … dishing out:
There are no fines for noncompliance.
Syntax error / compiler error / runtime error / query plan error …
All of which file under the aforementioned "consequences"...
The best names scripts are the ones that explain what you are going to do. Since we can store them in folders, we can name the folder according to what we want to do and have a main script with subscripts.
Short scripts are easier to debug
Short scripts can be performed by other scripts saving lots of time
Short scripts performed by a mother script can be writen and tested in short batches
With that in mind, a modular naming convention will enhance your performance.
Morning Update - Find new invoices to finalize
Morning Update - Post payments received in Mail
Morning Update - Print Report on Current Receivables
Re "FileMaker's own starter solutions do not now follow these guidelines", a couple of points:
1. From filemakerstandards.org, note: "These standards are not official standards from FMI, Inc.. They are contributed and managed by a core group of maintainers." My underlining.
2. Filemaker's starting solutions make no attempt to model a set of standards, or even necessarily "best practice". It seems to me that they, rather, are designed to demonstrate the sorts of things that are possible, a demo of what an average developer could put together reasonably quickly and easily. Whether they should go further, and model best practice—or even sound practice—is an argument for another thread. Suffice to say here that if you are pursuing the question of standards, don't lose too much sleep over the standards shown in the starter solutions. Read what other developers suggest, and filemakerstandards is a good place to start, and do what you feel comfortable with.
FWIW, I tend to use lowerCamelCase for field and table names and stick to alphanumerics (I really don't even like underscores). Field and table names can be called by lots of stuff - SQL, Evaluate - and anything outside of (and sometimes inside) FileMaker can be really picky about the name of the field / table.
Script names, I don't worry too much about. They tend to be descriptive and include spaces and the occasional "[" and "]" to indicate what parameter the script is expecting.
Why? Because the only time it matters is when you use them in a URL. I can URL encode for that, and the readability is nice. Others have different opinions, and that's fine.
Note also, however, there is a character limit on script names (can't remember what it is at the minute; maybe 128 characters?). So your naming convention shouldn't be too verbose or it'll bite you.
But YMMV. Just make it something that's (1) easy to understand and (2) consistent. For the sanity of everyone involved.
(1) easy to understand and (2) consistent
I would add that there should be an agreement on conventions if there are more than one developer working together. I worked in three different FileMaker development companies and they all used their own standards. It mostly workes as long as developers try to follow it. Although, this will mostly fall under consistency.
if you ever want to communicate with the rest of the world, then heed the warnings.
save yourself some time and make the names as 'standard' as possible (to the rest of the world) by using alphanumerics and underscore. if you think it's never ever going to be other than FileMaker, then go ahead with spaces. but do not use other characters that might otherwise be interpreted as a function symbol, or delimiter or oddity that makes the name likely to break even within FM at some point in the future.
Thank you all for the help and advice.