Naming Conventions

[Rabbie]

Following on from entries in a previous post (see http://www.access-programmers.co.uk/forums/showthread.php?p=612071#post612071 ) I wondered what people considered to sensible naming conventions.

For example should a table be called "Order Details", "Order_Details", "OrderDetails" or "tblOrderDetails".

Should variables in VBA be given a prefix which indicates their type eg strString or intInteger etc.

Lets have your views.

 

[Len Boorman]

I use a convention whereby the prefix indicates the object
tbl = Table
qry = Query
frm = Form
cbo = Combo Box

etc

Where a Report is based on say qry_Name_Places
then the report name is rep_Name_Places

When I use several queries to get the data set I want then I use the same query name with 01,02 etc on the end

I try to use meaningful names wherepossible with no spaces. I substitute underscore for a space.

VBA yes I use again a prefix indicating data type, txt, int,str etc

This is to a degree a personal thing and whatever works for you is good. No convention is the worst situation

Len

 

[The_Doc_Man]

Other posts have been made regarding naming conventions.

My own personal belief parallels Len's comments, so call this a vote of confidence for Len.

The worst convention is the one you make but then don't implement.

The best convention is the one that works well enough for you that you keep on using it.

The government standard naming conventions published by the U.S. Dept. of Defense sadly falls into the black hole in the middle - a really LOUSY naming and layout convention that governs whether you get paid for your work even though it screams "Don't Use Me."

The KISS principle also applies. Whatever convention you choose, Keep It Simple & Stupid. Just KEEP it.

 

[David Eagar]

I have found it very useful to have the grouping numbers first, so that corresponding queries, forms & subforms are grouped together, not spread out all over the alphbet

The first serious database I ever got involved in ended up with some 50 tables and many, many more queries - because of non existant conventions, it rapidly became a Stanley & Livingstone exercise to to find related queries & forms

ps it is 'nice' to know my incompetance has inspired something in this forum already (I'll try not to make it a habit)

 

[Len Boorman]

As the Doc points out. Have a convention. You have found out the consequences of not having a convention.

In a simple application with few of anything it is not so bad but a bad habit is a bad habit. Move the bad habit to a half complex application and you have the Stanley and Livingstone scenario

L

 

[doco]

Access MVP's have put this list together.

 

[Rabbie]

I agree with the consensus in this thread that a) a convention is desirable and b) needs to adhered to.

Personally I prefer the system of prefixing names with an indicator of their type ie tbl for table,qry for query, dte for a date etc.

I notice that the Northwind sample database does not seem to use any consistent conventions but thats life, I guess!

 

[doco]

I agree with the consensus in this thread that a) a convention is desirable and b) needs to adhered to.

Personally I prefer the system of prefixing names with an indicator of their type ie tbl for table,qry for query, dte for a date etc.

I notice that the Northwind sample database does not seem to use any consistent conventions but thats life, I guess!

Ain't if funny! You study, ask questions, buy books and they all say the same thing concerning some form of naming conventions. I have always thought it more than uncanny (looking at Northwind) MS chose not to take the advice of all their MVP's. Hmmmm.... what else are they not listening to ?

 

[ChrisO]

I think that the proposition that a naming convention should be adhered to is demonstrably false.

At what point do we say; “that’s it, I know it all, no more reason to change, nothing more to learn.”

I would think that very little needs to be adhered to while learning…and we are all learning.

Pick a naming convention and use it. Don’t be hesitant to change it. See what best works for you.

Learn and change as you go, that’s what learning is...change.

 

[Rabbie]

I think that the proposition that a naming convention should be adhered to is demonstrably false.

If you don't adhere to it surely it isn't a convention.

 

[ChrisO]

The convention we are talking about is the convention that others have created.

A person new to a subject has, by definition, no convention on the subject.

My aim with postings is to try to get people to a point that they stop simply using other peoples methods and start thinking for themselves.

 

[Rabbie]

The convention we are talking about is the convention that others have created.

A person new to a subject has, by definition, no convention on the subject.

My aim with postings is to try to get people to a point that they stop simply using other peoples methods and start thinking for themselves.

As the originator of this post I was trying to get a feeling how other experienced people felt about naming conventions. I found the replies interesting. From taking over other people's databases I find a convention is helpful in working out exactly what is what. Indeed it can be helpful when returning to a DB that has not been altered for some time.

A naming convention is at its most useful if it is one in general use and not a private one.

 

[ChrisO]

Maybe, but part of getting people to think for themselves also implies that they can not remain fixed on a particular standard.

For example: -
A little more than a year ago you started this thread as a means to learn. That implies you were willing to change if you saw something that was better than what you had prior to starting this thread.

You are three years older than me and you too still want to learn.

Standards and conventions are only reasonable to the point that they should evolve with us. However, some younger people may believe in that ‘silver bullet’ that solves all ills for all time.

I think both you and I (and others) know that that is not the case and hence my need to try to explain.

Regards,
Chris.

 

[neileg]

I'm pretty much in agreement with you Rabbie. I use tbl, frm, subfrm etc. I don't like the underscore so I just don't have any punctuation or spaces in my object names.

So far as M$ following it's MVPs, how about doing some simple things first? Wizards that don't generate obsolete unsupported code? A form wizard that doesn't use the bound field name as the control name?

 

[Simon_MT]

Naming conventions should be coherent and self explanatory. I agree with most of the above but a table is table and a form is a form. A query is simply a 'view' so there has to be a distinction between tables and queries.

I prefer to associate subforms names with the parent by appending Originals / Originals History / Prints / Prints History / Exhibitions and Consignments to a main form like Artist Entry to give Artist Entry Originals. From this we can ascertain that it is an Entry point and it is subserviant to the Artist Entry form. We also have Enquiry screens that surpresses stock values so a similar naming convention applies.

I understand that 2007 does not allow database object names to be duplicated so each object's name must be unique.

I prefer to categorise objects like suites within an application so all associated objects Tables, Queries, Forms, Reports and Functions focus on a particular area of the application rather than the type of object. I never use a prefix or a suffix when referencing a Table.

Once you have decided on a naming convention stick to it but remember its the efficacy of your application that is more important.

Simon