I have no count of the number of times I've turned up at a client's site to carry out either an audit of an Access database or had to repair or redevelop parts of a database only to find myself hunting around wasting valuable time looking for associated objects, dependencies and other related controls when a simple policy of adopting some sort of naming rules and thus standardise an Access database would have been just the ticket; a ticket that may have said "Discount" on my invoice to the client! Naming objects with Microsoft Access databases (i.
e.
Tables, Queries, Forms, Reports, Macros and Modules) using a derived set of conventions and prefixes makes users, developers and other members who will inherit an Access database lives more bearable and manageable for future maintenance.
Microsoft Access does not impose any disciplines and life can become chaotic unless users take care right from the very start.
So, the following conventions will elevate and avoid problems.
Putting aside VBA programming for now and just focusing on the objects readily accessible in an Access database, there are two sections I want to highlight in this article for now to get you started:

1. Naming conventions for your objects in your database
2. Naming conventions for extended objects in your database

Objects in Access The following prefixes can be applied to the main six Access objects:

1. tbl = Table
2. qry = Query
3. frm = Form
4. rpt = Report
5. mcr = Macro
6. mod = Module

When saving a new object in your Access database, use the above prefix (in lowercase) and optionally add an underscore character ( _ ) as a separator if required before specifying the name of the object.
For example, a table (list) of employees might look like tbl_Employees or tblEmployees.
Notice how I've capitalised the first letter (and for each word if more than one word is used) as well as making it plural as it is a collection of individuals.
Also note, though Access is not fussy, I tend not to have spaces at all between words or anywhere in the naming of objects as a rule - its good practice in general and more of the 'old school' approach especially when programming Access using VBA.
Extended Objects in Access The first section covered the essentials and once mastered users can consider extending Microsoft Access object a little further and be more explicit in adding a type of use for an object.
For example, Access Forms are screen interfaces that end-users will interact with but the types of uses for a form will vary from main input or read only form to a dialog box (pop-up) and a message box.
To help expand on this, the following list maybe extended to help identify and group types of use for various Access objects:

1. frm = main form
2. fdlg = dialog form
3. fmsg = message form
4. fsub = subform
5. fmnu = menu form
6. What about the other main objects? Well, here's some more:
7. tbl = main table
8. txls = Excel table link
9. todb = ODBC table link
10. ttxt = Text file link
11. tsql = SQL table link
12. qry = main query
13. qapp = append query
14. qupd = update query
15. qmak = make table query
16. qdel = delete query
17. qxtb = cross tab query
18. rpt = main report
19. rsub = sub report
20. mod = main module
21. bas = main standard module
22. cls = class module

There are many others too but you can create your own and don't even have to follow the standard ones above.
As long as you keep it consistent and other users work with you, then your own code of working practices will pay dividends in the long-term.