Naming conventions

[jtwilber]

Ok.. as I start to slide down the slope into FM I'd like to get into good habits. Is there an industry standard system for naming databases, fields, scripts, code etc etc that I should get into the habit of using to make me more user friendly in the future?

[EddyB]

For global fields, developers normally place a g in front of the field name e.g. gField1

For Calculation fields, developers normally place a c in front of the field name e.g. cField2

Ed

[Ugo DI LUCA]

Hi,

Friendly on Forum -----> g_global, n_num, t_text, c_calc, d_date, h_hour,...

Efficient in your own db -----> Check Kennedy's post in the Sample for his last Starter Template as included is a cool pdf file with some "naming procedure" for developpers.

zk_keys

zu_User Fields......

This last method is really a great path in my opinion, as every fields may be sorted in Define fields but would always appear with their own use. Besides, when it comes to work on several project , and when a file could hold as many as 200 field +, it's kind of very useful to immediately locate a field based on its use.

[CobaltSky]

Ah yes, standards! They are a somewhat thorny subject.,

The fact is there are any number of published 'standards' - self proclaimed as such, and self-evidently not standards since none has universal acceptance. In fact despite the claims some of their authors make, few have better than marginal acceptance. I work for various clients who have adopted different sets of 'standards' - some of which are of their own invention, and so I have to follow different practices on different projects (sometimes concurrently, which can get a little 'hairy').

A couple of the better known (if not widely followed) published 'standards' documents are available free from the following URLs:

http://www.dataworks.ca

http://www.coresolutions.ca

In them - and the various other documents like them which are in circulation - you'll find suggestions, recommendations, dictum and dogma which ranges from plain common sense all the way through to arrant nonsense.

Nevertheless it's a good idea to have a look around and see what is being suggested and why - so when you depart from a given approach, you know you are doing so and you know why.

Certain conventions - such as the ones Eddy cites - have fairly broad acceptance (though interestingly you'll find that the way they are used by a majority of developers is not in line with recommendations in a number of the published 'standards' documents.

Perhaps more important than wholly embracing any single set of standards, is to adhere to a consistent approach - at least throughout a given solution - and to look always for the simplest, most logical and most 'compatible' (across platforms/environments/media) approach.

[jtwilber]

Thanks everyone. I've downloaded the files and will work on at least being consistant with my work and pickup what makes sense from others.