Best Practices

[bcooney]

I recently responded to a post and added the comment, "it's just best practice." Well, of course, the followup was, "where do I find a list of best practices." Hmm. Is there one? I've read FM's Dev Conventions, the WhitePaper for Novices, but where is there a best practices list? Nothing found on Google. Should we attempt to write one together via the forum?

[Lee Smith]

There are some White papers out there.

I just did a Google Search for [color:blue]FileMaker Naming Standards and came up with several hits. There has been a lot of discussion about this in the past, here is one site (besides FileMaker Inc.) Link also, I remember a second site, but I can't seem to remember off hand.

If I think of it later, I'll add a Reply.

HTH

Lee

[Vaughan]

Lee and Barbara

I'm doing a "standards" document for my organisation, and it's quite hard knowing what to include.

For instance, I don't particularly have any rigid guidelines for naming conventions as long as the field name is valid by FMP's standards: I only recommend that they be human readable and descriptive (and leave the reader to define "descriptive" as they see fit).

This contrasts with my recommendations for the use of global fields, which is very prescriptive: don't use globals to store any data between sessions, use a single-record Preferences table for this.

In fact, so far, the thing about the globals if the only entry in my document. I added this after finding *another* file in my organisation that uses a global field to store data, which means it cannot be changed while hosted in FM Server. Grrrr.

[bcooney]

I'm thinking beyond naming conventions, such things as "build relationships matching key fields and not strings."

[Vaughan]

Barbara

Ok sure, that certainly is best practice. Key fields should be unique and invariant, and have no meaning.

Anything else? I'm taking notes here! :)

[Genx]

Well as a general note, i use camel casing and specify first a data type, followed by an underscore, (followed by storage and another underscore if applicable) followed by the fields name.

dataType_[storage_][const_]myFieldName

e.g:

d_myDateField (date field)

n_myNumberField (number field)

i_myTimeField (time field)

m_myTimeStampField (timestamp field)

r_myContainerField (container field)

ct_u_myCalculationField(calculation result text - unstored)

cn_s_myCalculationField (calculation result number - stored)

cr_u_myCalculationField (calculation result container - unstored)

t_myTextField (text field)

t_g_myGlobalTextField (global text field)

ct_s_const_myValue (a calculation result text - stored - that has a constant value for the purpose of relationships - the value is, where possible, "myValue" )

I find its a lot easier to deal with them in relationships, calculations etc given that there's still no other way to see the data type with the advent of FM 9.

Edited July 25, 2007 by Guest

[bcooney]

OK, good, thanks for chiming in Genx. I was hoping to hear from all the regulars.

I was discussing this with my partner since we've always planned to write a conventions doc for us. We have at least created the ultimate starter file!

I'm wondering what the FM Dev Conv doesn't cover? What doc would we like to post for new users that doesn't repeat the FM Dev Conventions doc or the WhitePaper for Novices? It's difficult, because sometimes it's a matter of development style or design aesthetics. I don't want to include such things.

Can we toss around sections of the doc, and create an outline? We could vote, lol.

Proposed Sections:

Naming Conventions (see FM Dev Conv)

Relationship Graph (see FM Dev Conv)

Relationships

Managing Windows

It's hard. I think of a collection of techniques. Well, just go to JMO's site!

Are we reinventing the wheel? Maybe just a set of links for beginners?

[mr_vodka]

I would also add some info from this link.

http://www.kevinfrank.com/anchor-buoy.html

[Heathbo]

Has any work progressed on this? Since I haven't adopted any advanced conventions, I am really curious to see what coventions people here use. I've read conventions documentation like the white pages. Though it would be really nice to hear from people that use them. A real world point of veiw. It would also be helpfull to have a pros and cons of all the different conventions. I know thats a monumental task, but its a wish list.

[MarkWilson]

Here is the basis for what I use.

[Heathbo]

Thanks Mark.

Heres a thought. Lets get everyone to post the conventions they use. Then let the FM community vote on it. I think this way we can come up with the best of the best "Best Practices". Of course we would vote on one section at a time. Naming conventions for example. Then after all the voting is done. Documentation of the winning conventions can be made available to the fmforums community. I think this would be a great way to bring together the vast amount of exerience this community has to offer. Just a thought. What do you think?

[Vaughan]

"Heres a thought. Lets get everyone to post the conventions they use. Then let the FM community vote on it."

Please, no.

It'd be as useful as a vote on people's religion.

I'm personally moving towards a document with suggestions on what NOT to do. Like: "Don't store data that needs to persist between sessions in global fields."

[Heathbo]

Ultimately, what I would really like is to see the different conventions in one place. Instead of piecing it together from different documents found on the web. A what not to do list would also be great. I would like to see what this community uses and why.

[Genx]

A what not to do list?

You realize that implies that the person who was to compile this document would have to think of everything any new developer may be inclined to do (rather than specifying any valid conventions) and compile that list telling them in detail why they shouldn't do each and every thing that they very well may do...

You know, kind of like "Don't do what Johnny Don't Do Does", seems sort of backwards to me.

[Søren Dyhr]

This topic is both interesting as well as pretty boring, but what I seems to have summarized over the years with various debate fora are the usual troubles encountered with newbes is the stubborn unvillingness to really get the gist of the tool.

There is a lot of tire-kicker assumtions like it's either a spreadsheet with an extra 25% layouting overhead, or if the entry is made from business administration or as just another "Library" or programming language if the arrival is made from genuine lowlevel programming.

The plentora of features in one direction and felt omissions in the other will usually confuse a newbe in his/her first encounter with the tool. The near endless permutation of nearly concurrent tool features found on the marked, makes usually a spoilt for choise situation, which can be blocking ...or rather the assumtion that pre-emptive planning ahead seems needless.

Would I be happy if the perfect tool showed up? No it's actually quite inspiring to circumvent limitations with a dose of ingenuity - I would be bored to dead if the adrenalin rush dissapeared and should be substituted with linear thinking.

Tool trespassers would never have accomplished something like "Sgt. Peppers Lonely Heart Club Band" ...in this particular case is the wisdom gained or pulled upon the near endless shows in the Reberbahn, Hamburg in their green youth, where most of the tricks of the trade crept upon them as a cheap coat gradually.

It's important that the newbe realizes that one thing is marketing hype, but the reality is that shortcuts doesn't exist - you need to get the skills and a genuine dedication to match the posibilities as well as limitations the tool exhibit!

Perhaps is the word that nails what it really takes: "Humbleness"

--sd

[Vaughan]

"I would like to see what this community uses and why"

Many conventions (such as field and table naming conventions) are arguably arbitrary. They are designed to either make sense to the developer (conventions that include the type of field and other information in the name) or to the end user (the name indicates what information is in the field).

So to store a person's first name, the field could be called:

Txt_Name_First (developer centric) or

First Name (user centric)

I also don't believe that a conventions document can also double as a learning manual. The conventions manual can only make sense to people that already know how to use FMP to develop databases.

Hence my argument that it's better for the conventions manual to say what not to do: "don't use any illegal characters, FMP will warn you but let you use them anyway, but resist the temptation they'll bite you later."

Then possibly give a couple of examples of naming conventions that illustrate the more sane possibilities.

I was going to say "be consistent with field names" but really, what does it *really* matter if the first name is called "Name First" and the last name is called "SURNAME"?

[Søren Dyhr]

I also don't believe that a conventions document can also double as a learning manual. The conventions manual can only make sense to people that already know how to use FMP to develop databases.

True- excellent point!!! The main ingredient in improvisation is knowledge of what to ignore, not closing ranks behind a doctrine - where the "why's" seems irrelevant. Sensemaking requires questioning not stiff rules.

--sd

[Heathbo]

Your right Soren. The what not to do's has to be learned and experienced. Other wise its ignored.

To sum up all my previous post: I wouldn't consider myself a newbie, as I've used FileMaker on and off for many years. More often in the last two years. I've even taught FileMaker basics at the local Apple store. I want to move beyond the basics though. So the reason I want to see what others use is because I know the conventions I use (nameFirst, nameLast for example) aren't as efficient as I would like. I was thinking that seeing what others use might give me some ideas on how to improve what I'm using. I'm also trying to improve my TOG organization. Again, I was hoping that I might get some ideas if I saw what others here use. Anyway, looks like I'm back to scrubbing the internet.

[Genx]

Even the conventions documents, especially the formal one of a group of FM developers who decided to get together and write one up, isn't 100% clear on the issue.

At least in terms of field naming, all it really advocated was consistency:

1) camelCase

2) TitleCase

3) delimted_name

Further it recommends not using illegal characters or whitespace in your field names to guarantee optimum co-op with other programs and languages like sql.

It further goes on to suggest that some developers may choose to prefix their field name with a field type.

I myself will generally camel case and use the prefix as such:

t_myTextField

The point i'm trying to make though is that there are a fair few accepted conventions, most of them are common sense and simply advocate consistency in usage.

FM is however far to broad a tool to be put together in a what not to do doc.

[Tori Mitchell]

Dang... it's amusing that this topic has been active these last few days as I've had to do a lot of this kinda thing recently (taking on two new developers will *make* you do this, BTW)

This is a topic as old as the hills in traditional computer science however, we all know that FM has some very interesting things about it when it comes to the generally accepted development standards of the developer world.

Genx:

As to what casing you use, that's always going to be a matter of opinion and, generally, the lead developer wins that argument hands down and it makes everyone's lives easier to use the same thing.

Here's what I use:

l_userFirstName_t <<location_noun_type>>

The reason that I divide the location and type data up is simply that I cannot remember what every field is and does at any given time so I'll often setup 'audit' layouts with just the local data to the table. The type only really comes in handy after you know where it's coming from.

So:

lcs_userFullName_t = local calculation stored - text field

cu_totalUsers_n = calculation unstored = number field

s_userAverageAge = summary

What's wonky about this is that it already breaks the rule that I have about separating the type and location *however* I've found that you may often want to have a layout with no calcs at all for data viewing purposes. Putting the contextual clue there that it's a calc can get around this and if you want to include the locally stored calcs in the view, that's doable too.

I use lower case camelCasing because of the visual divider between the location and the noun. This is simply a style issue. I tend to not use '_' delimitation because of the fact that it's separating up the noun into two chunks or more. The underscore is used to break up information in my scheme.

For primary keys, I always just use __ID_pk_at (ID, Primary Key, Auto-Text Field). I can live with having all my PK's look the same because I like it. The data is always different, just not necessarily the field name. I'm still not sure if this is a good idea or not. The double underscore takes the PK to the top of the sort when you click on the field sort in field view.

Foreign keys are similar:

_fk_createdBy_t (foreign ket, createdBy, text field)

Again, the underscore sorts it to the top but not above the PK.

*whew*

And that's just field names.

Edited October 25, 2007 by Guest
forgot something... again

[David Jondreau]

I'll throw my hat into the ring...

I began sorting all my fields manually a few months ago and love it. Out of habit though, I still name my keys

_kp_idTable

_kf_idRelatedTable

_kg_1 (for global keys)

_kc_x (for calc keys)

For all other fields, I'll use a leading lower case character in a few cases, namely c for calculated fields (cTotal) and g for globals (gDate), and z for some utility fields (zSortField).

Otherwise I'm CamelCase all the way. In Define... I can see if a field is number, calc, etc, and I find the extra characters in the field name to just be confusing and I'll usually know by looking at the name what it is (if I need to).

I used to use names to alpha organize fields (AddressStreet, AddressCity, AddressState) but after listening to Matt Navarre on the Adatasol podcasts, I changed to a custom sort which I like a lot better, so I don't worry about that anymore.

Note I don't think my method should be adopted as a convention, it simply works best for me.

As far as TOGs, I'm into the modified A-B, more of a Functional Table Occurance Group. I like my groups to read left to right, spreading out from the base table, but unlike the standard I've seen, I color all the base tables the same (within reason, this starts to get tough with 10+ tables, but I usually color similar groupings (Contact-related tables frex) with similar color themes (Blue-Green)). I name TOs: parenttable_firstrelatedtable_THISTABLE with an additional _ThisFunction on the end if needed.

And I use colored backgrounds for groups and small notes for commenting.

[bcooney]

Since I started this thread...

I use the text tool in the Relationship Graph to create a "key" of TOGs. The text box is the same background color as the TOG (all members of the tog are one color). The key is in the upper left corner of the RG and is laid out in the same order as the TOGs appear in the graph. TOGs are situated close to other TOGs that are within the same "module," if you will.

I do not use PTO_TOs anymore, as suggested for local calcs. I have one "anchor" TO for each table, and all local calcs are from its context.

I don't use global calcs much. I've seen weird behavior. For example, if you define a global calc=1, it won't equal 1 until you create a new record in the table. So, rather than having global calc fields = pref field, I use an Opener script to populate globals with the prefs values using Set Field steps.

I name my scripts, ScriptName [Parameter], if any. I name my value lists, Name [ ID - Field ], and if they're from related, then "from Invoices."

And finally, I try to leave myself "breadcrumbs" for anything not complete. Buttons are garish aqua, fields on layouts for dev purposes have gold background colors, gold background notes on layouts, scripts have ** if not complete/tested. I wish there were Layout comment areas! Comments galore: in field definitions, scripts, calcs.

[Heathbo]

Further it recommends not using illegal characters or whitespace in your field names to guarantee optimum co-op with other programs and languages like sql.

What other programs and languages are you referring to? I'm asking because I find it sometimes annoying to not have spaces. Especially when duplicating fields and all I have to change is a number or letter in the name and/or code. I can then double click on the word or number that has to change. Knowing what systems this causes issues with may help prevent future problems.

[Genx]

Mainly SQL / anything you want to hook into via ODBC - there are a lot of SQL systems out there, some are more fickle than others. Plus it saves you using quotes in PHP.

Just use under score wherever you would put a space normally - how often do you reaalllly duplicate fields that it becomes that annoying.

[Heathbo]

how often do you reaalllly duplicate fields that it becomes that annoying.

I only do it when I'm creating calc fields for each day of the week or for many weeks, or months. The only thing different in this case is the day/month/year number.

[Heathbo]

And finally, I try to leave myself "breadcrumbs" for anything not complete. Buttons are garish aqua, fields on layouts for dev purposes have gold background colors, gold background notes on layouts, scripts have ** if not complete/tested.

Thats a great idea. I see how that can be usefull.

[comment]

I'm creating calc fields for each day of the week or for many weeks, or months. The only thing different in this case is the day/month/year number.

THAT doesn't sound like good practice.

[Genx]

THAT doesn't sound like good practice.

Yeh, I'd agree there... you could probably just use a repeating field in this situation. Heathbo, go start another topic and describe why it is that you're duplicating this many fields, maybe we can help you :(

[Heathbo]

alright, here is the Link

[Vaughan]

"Yeh, I'd agree there... you could probably just use a repeating field in this situation."

ROTFLMAO.

[Genx]

Why... Its a series of duplicated fields relating specifically to dates, where the only difference mentioned was the day, month and or year. Depending on the exact purpose a repeating field, and / or repeating calc could be suitable here. But given that it depends on the actual facts I recommended a new topic be started.

You can't just laugh at something that is not necessarily inherently humorous to everyone... well i don't get it anyway... and not explain your reasoning.

[Heathbo]

I just attached an example file in the new topic.

Oh and Vaughan, I can assure you, I wouldn't laugh if there was something you didn't know.

[Vaughan]

"You can't just laugh at something that is not necessarily inherently humorous to everyone... well i don't get it anyway... and not explain your reasoning."

I can... because I am EVIL!

Bwah ha hahhhh!

Bwah ha hahhhh!

Bwah ha hahhhh!

[nick_jp]

Good thread. The document that is missing is the "Quick and dirty start sheet for people who know a bit about programming already." There are tons of books which spend 700 pages explaining what a relationship is to beginners....

Things like:

1. Use a global to drive a dynamic portal.

2. No you don't have SQL, but here are 10 examples of how to use the find command that cover 90% of your searches.

3. You can separate Front and back ends if you want, do it by selecting another file when you add a TO on your font end relationship graph.

[Søren Dyhr]

Quick and dirty start sheet for people who know a bit about programming already.

Isn't it easier said as simple as? "Don't mistake the tool for being something else - be it Word, Access or Excel for that matter"

--sd