Naming conventions

NW27

New member
Local time
Tomorrow, 08:12
Joined
Oct 6, 2011
Messages
6
Hi,
I'm just starting on VB and Access.

What do people generally use in naming conventions ie
1. do they put tb in front of a table? tbFred
2. rpt in front of a report? rptMonthlyProfit
3. Primary key on a Table called Fred. Do they use ID or Fred_ID as the primary key column name?
4. Forms ???

What other naming conventions are there?
Index's for example.

Neil
 
I wouldn't get too bogged down on them but as for me (and my employer) we use

For Tables - tblTableName
For Queries - qryQueryName or sbqryQueryName or mtblQueryName (for make table) or delQueryName (for delete) appQueryName (for append) and ctqryQueryName (for crosstabs)
For Forms - frmFormName or sbfrmSubformName
For Reports - rptReportName or sbrptSubreportName
For Macros - mcrMacroName
For Modules - basModuleName

For PK's we use FieldNameID
For FK's (much to my chagrin) we use FieldNameFK (I would use the same name as the PK)
For fields - we don't use them
 
Thanks Bob,
Neil.
 
Personally I avoid using the underscore in names. It detracts from readability of the name by separating its parts and adds nothing but an extra keystroke (with a Shift to boot).

The underscore also has a built in purpose for naming procedures in the modules and I prefer to reserve it for that.

I am also not fan of Hungarian notation. Its benefits are highly overrated and adherents tend to ignore its down sides.

One part I find particularly strange is the frm and sfrm for Form and Subform respectively. I have forms that are used both as forms and subforms, so what should that be called?

But as Bob says it really comes down to following the workplace convention. I am the only developer where I work so I do what I like.
 
.

One part I find particularly strange is the frm and sfrm for Form and Subform respectively. I have forms that are used both as forms and subforms, so what should that be called?

As with everything there usually is some "exception to the rule" which is inevitable. So a lot of it is personal preference (unless dicated from above) but whatever you choose to do, be as consistent as possible and that will aid anyone coming in after you to be able to look and understand it (hopefully).
 
Naming conventions can get anal. Most of my subforms are used for an overview and not entry, the exception is notation information. I relate the subform to the parent:

Exhibitions Entry
Exhibitions Entry Originals
Exhibitions Entry Prints etc.

I would just add, that I tend to arrange Subforms as Tabular rather than Stacked so alternate colours can be used.

As Access already catagorises Tables / Queries / Forms / Reports / Macros and Modules it seems somewhat superfluous to name according to a convention. However, as fiunctions are used exclusively, naming conventions have to used as there are so many and once again, reference is made back to the Form or Report / Control & Event.

I do use spaces, me bad, but it is a hell of lot easier if you are dyslexic, less keystrokes and besides in many instances [ ] are used to refer to an Object and that aids pattern recognition.

The most important of all is that someone can understand what the information actually relates to so just be meaningful.

My databases are not perfect and neither are they 100% consistent - life's too short.

Simon
 
Neil,

I find it interesting that you have asked this question at this point in time because just yesterday I posted my latest article on my blog on this very subject. If you would like to read it you can find it at: http://blog.askdoctoraccess.com/

Leave a comment if you like as I would like any thoughts on the subject.
 
to be honest, i don't think any of it matters so much. I do tend to put tbl in front of tables, and gbl in front of public globals.

i try and create types to store public variables, and i always precede them with a t, and then define the variable as a similar name

i try and avoid putting spaces in query and form names, but sometimes i inherit stuff with them in.

In any event in a medium to big database, i will easily end up with in excess of 100 queries (and forms), probably many more, and any naming convention becomes a bit moot. Prefixing queries with qry helps a bit, but it is often still hard to find the one you want, and you almost always end up duplicating the functionality of some queries.

i tend to give fields a prefix resembling the table name. so for tblcustomer, i would probably have fields call custid, custname, custaddress etc, but again, it isn't the end of the world is some aren't prefixed that way.

The most import thing, i think, is to plan the database - normalise properly, analyse the functionality that is needed, and then write code that is well modularised, uses parameters where possible, is well documented, has good error handling
 
Thank you everyone for responding.
It is greatly appreciated.
Neil.
 

Users who are viewing this thread

Back
Top Bottom