Like Brent, I do not like using the 'g' for globals because I don't want
my variables mixed in with my other fields. I used to start my global
names with an underscore, which sorts them to the bottom. But then I
realized that there are no guarantees that underscores will always sort
to the bottom in any future versions, so I now use z_FieldName.
I also do not like starting my calcs with c_ or calc_ because I do NOT
want these segregated from my other fields. Often, I may not know
whether a field I am looking for is a calc or a regular text field in
any particular table/file. By listing all fields (except globals)
alphabetically, they are easy for me to find. I do append an _c to the
end of the field name so that I know it is a calc and therefore not
modifiable.
There is a nice, structured guide of thoughtful naming conventions at
<http://www.coresolutions.ca>. (The website seems to be down at the
moment so I can't get you the specific path.) These were put together
by one of the partner-level members of the FileMaker Solutions Alliance.
I personally do not follow many of the conventions in this guide for
the reasons stated above.
The real point of all this, is to be methodical and consistant. Once
you come up with something that works for you, stick with it all the way
through the project.
> The usual FileMaker convention for global variables is to start each
> field name with a lower case g. However, I have found that awkward,
> since it intersperses file variables and other specialty fields within
> normal record fields. In order to move those fields to the bottom of
> the list and to group them according to function, I have found it useful
> to start a variable with a lower case "zv," a calculated field with a
> lower case "zc," etc.
> Brent
>> Hello
>> What I usually do is this:
>> calculation field: Calc_fieldname or C_fieldname
>> global field: G_fieldname or Glob_fieldname
>> After you have to be more creative.
>> If you have a layout called: Hotel details
>> you can name your fields such as: H_D_fieldname
>> that way you know right away what the field is for.
>> But I don't know a good site to describe this.
>>> Hi all,
>>> I have set up several databases now, but I'm always a little bit
>>> clumsy with
>>> giving proper fieldnames. As the db is growing bigger and bigger, the
>>> fieldnames are getting more and more strange.
>>> As observing this ng I found everyone using "gFieldname" for globals.
>>> Can anyone point me out to smart sites where i can find good ideas for
>>> consistent fieldnames.
>>> For instance you often have, what i call, an input-field, in which
>>> the user
>>> inputs data and there's a resultfield where the input of the user is
>>> tested
>>> (or calculated or whatever).
>>> How to properly name those fields.
>>> How do you setup your db? Any Ideas?
>>> thanks
>>> Rienk
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg (818) 883-2846
FM Pro Solutions Los Angeles, California
Associate Member, FileMaker Solutions Alliance
by