I am writing up a nomenclature documentation. This nomenclature makes use of name spaces and creator codes in name spaces. Anyone know of anyone using or managing name spaces or creator codes the FileMaker world? I would prefer to coordinate with an existing system instead of creating a redundant system.
Could you please clarify the expression creator code? I’ve never heard this before in all the years I’m working with FileMaker. 
I am equally ignorant of that concept and found this on Wikipedia:
https://en.wikipedia.org/wiki/Creator_code
1 Like
Happy new year everyone!
My bad! I should have explained. The creator code I am referring to is a code that designates a person or organisation that creates / created a piece of code… in this case, a custom function. Here is the problem space being solved with namespaces and creator codes.
Namespaces allow the grouping of custom function according to function type, feature, whatever. Grouping can allow for easier finding of a function in a large set of function – we use a lot of custom functions at my company. Grouping can also allow for the re-use of function names – very useful.
Creator codes are added to namespaces. This allows custom functions from multiple developers that have the same name space and function name to co-exist. It is also a form of self-documentation. We find it especially useful to know which custom functions were create for our own reasons and which were created for customer specific reasons.
I hope this clears things up. Thanks for your feedback.
4 Likes
I also wish everyone a happy new year!
Thank you for your explanation @bdbd ! This input is very timely. I had planned to think about development standards in the coming weeks. You partly mention things I hadn't thought of yet: e.g. the naming of custom functions.
Basically, I use an abbreviation like FSO21 (= fmSoup 2021) for my customers, sometimes even for large projects. A three letter abbreviation for the name plus the year the collaboration started. I use that so far for file names, folder names, tags, etc. Oddly enough, the idea of using this for programming as well hadn't even occurred to me.
Otherwise I like to group field names by naming them: e.g. the metadata fields of a record I start with "meta_" - a kind of group name prefix. System or function tables I start with "App_". Prefixes for layout names I have largely coupled to the table prefixes.
All of this has so far been little strategically thought through, but rather a gut feeling.
I will think about it more carefully! Thank you for your input!
Part of the problem with custom function names come directly from FileMaker itself, specifically in regards to name length. Regardless whether some consider this an artificial limitation or not, I needed to resolve this issue sooner than later… and I have.
My creator codes are always two characters long. This affords me a hopefully long enough list of potential creator codes, yet consumes little visual real estate when viewing custom function names in FileMaker.
I found this solution acceptable in regards to code readability. It strangely increased readability. Creator codes only exist in custom function (so far at least). We find it easier to identify custom function names as references to custom functions in calculations. That said, I doubt this would be true of a stranger reading our code.
1 Like
Change management and release management are both sorely lacking in FM development; an artifact of most systems being single developer based. This becomes painfully apparent in larger scale situations with a development team, and exacerbated by solutions that have a long life, with changing staff implications.
Attempting to enforce comment blocks in code with a standard format is difficult regardless of how useful it is. And enforcing SDLC process in code that has non change control mechanism takes a level of programmer discipline that is uncommon.
If Claris would just add a change date to edited code in script workspace, that would be a major - albeit it incomplete - step in the right direction. Especially with future FM releases geared to much larger scale deployments.
1 Like
If you save the file as xml, you'll see the script last change date and the user who did the change:
<Script id="60" name="dev_MultilinefelderAufFlacheVerteilen">
<UUID modifications="7" userName="iw" accountName="cendrars1%" timestamp="2022-08-16T13:57:18">C85A3A18-AD62-455A-BFE2-F0D6DF44F764</UUID>
<Options hidden="True" access="ReadWrite" SiriShortcutVisible="False" runwithfullaccess="False" compatibility="0">8</Options>
<TagList></TagList>
</Script>
NOTE: This change indication only starts in the moment of the first "Save as xml" execution. So you'll see it only from the second saved xml and all subsequent ones...
1 Like
This can be somehow helpful, but falls short of true version control for development in teams. FM is stuck in a pre-2010 past.
1 Like