In database development it is a good idea to use some sort of naming conventions similar to the ones listed below by Leszynski/Reddick. Why? Because the next Programmer to come along should not have to try to figure out whether my query is a make table or delete query! They shouldn't have to guess whether the form is a main form or a subform. You do not have to use the one below as long as you implement some sort of naming convention.

The ones I commonly use are in bold print.
My Table Naming Conventions...

I then use the Table names as prefix values for the field names, ie...

cpClientID (Primary Key, Autonumber)

pProjectID (Primary Key, Autonumber)
My Naming Conventions...
For those of you that use UDF's (User Defined Functions), you may want to consider prefixing those as well or Access could consider your *getSetting()* as its own GetSetting(), a member of Interaction, which will produce an error.
One side effect of using Reserved Words for Field Names...

Code and Description had been used as field names in the table

...then placed a Combo Box on the form using the Table with those two fields as the Row Source for the Combo Box.  When typing in the Combo Box it would not accept the value being typed instead giving the error message, "The item you selected is not in the list..." but it was in the list!  This is because Access could not resolve the field names of Code and Description.  Once the field names were changed to
tCode and tDescription the Combo Box behaved as expected accepting the values whether typed in or selected from the list.
When it comes to Table names I like to use comprehensible names, ie...
The difficult I do immediately, the impossible takes a little bit longer.
Tips (Main)
Where are the Options?
Options for Current Database
Object Designers
Trusted Locations
Repair (or Remove) MISSING or Broken References
Export Specifications
Import Specifications
Navigation Pane Options
Setting up a Model Database
Default Buttons and Legend
Set Subdatasheet to [NONE]
Creating a Settings Table
Not_In_List Event
Handling Attachments
Database Design Tips
app Application   g Public Variable (Global)   qmak Make Table Query
b Boolean (Yes\No)   gra Graph   qry Query (or qdf QueryDef)
bas (or mod) Module   grl Group Level   qspt Pass Thru Query
bln Ballon   grp Group   qtot Totals Query
bof Bound Object Frame   h Handle to Windows Object   quni Union Query
brk Page Break   hlk Hyperlink   qxtb Crosstab Query
byt Byte   idx Index   r Parameter passed by Reference
c Count of some object   img Image   ref Reference
cbo Combo Box   int Integer   rel Relation
chk Check Box   lbl Label   rpt Report
cmd Command Button   lin Line   rst (or rs) Recordset
cnt Container   lng Long   s (or sng) Single
con Generic Contants   lst List Box   scr Screen
ctl Control   m Private (module) Variable   sec Section
cur Currency   mod (or bas) Module   sfr Subform
db Database   obj Object   shp Rectangle (Shape)
dbe Database Engine   ocx Custom Control   sng (or s) Single
dbl (or db) Double   ole Object Frame   srp Subreport
dcm DoCmd   opt Option Button   str String
doc Document   pag (or pge) Page of Tab Control   tab Tab Control
dtm Date   pge (or pag) Page of Tab Control   tbl Table (or tdf TableDef)
err Error   prm Parameter   tdf TableDef (or tbl Table)
f Fixed   prp Property   tgl Toggle Button
fld Field   prps Properties   tlkp Look-up Table
fmnu Menu Form   qapp Append Query   txt Text Box
fmsg Message Form   qdel Delete Query   usr User
fra Option Group (Frame)   qflt Filter Query   var Variant
frm Form   qlkp Look-up Query   wrk Workspace
f Function
s Subroutines
Doing this serves two purposes for me...

The first, it insures that I do not use any Reserved Words (for a list see Reserved Words in Access), which Access would not like and I would have to use brackets around, like [Date] and hope Access still didn't object. Access 2007 and up gets especially *upset* when faced with a field or table name that uses one of its favorite words.

The second one, when reading my code months or even years down the road I know immediately which table the field comes from.

I also never use spaces or underscores or special characters... Spaces and special characters mean I have to bracket field names and/or table names. Underscores is just one extra character to type. Okay, now you're thinking, what's the big deal? Less typing... when you realize you're going to *type* code and lots of it... Not only is that pesky underline just another character that must be typed in the name, it is not an easy character to type. (Hold down the Shift key, then reach with the little finger, or is it the ring finger, and hope you hit the right key.) Just leave it out, use Camel
Back and your field names will be very easy to type and read! (Thanks to Victor R. for the suggested amendment.)

And, just so you're not stuck with just my point of view...  Tony Toews Naming Conventions
This site uses cookies to collect data on usage. By continuing to browse this site you consent to this policy. Find out more here.