There are multiple standards out there. SJ gave you one that is common. Others exist. SJ tells you about prefixes, and that can help for some things, but there is another side of the same exact issue.
A far more important consideration is that you first must make up object names that have meaning in the particular context. Like, if you are dealing with parts having an SKU number, call it SKU or SKUNum or something like that. Don't call it GEORGE. This is referred to as having "mnemonic" value from the old minor Greek goddess
Mnemosyne (I think I got that right).
Next, you had better get used to either having very long names or very cryptic ones. But choose one or the other, TRY to be consistent, and totally avoid names that have no meaning whatever. Like, Label11, TextBox12, ...
Now, there's a GOTCHA waiting here on the above topic. If you use a wizard to create something, DON'T TRUST IT TO USE MEANINGFUL NAMES. It won't. Go back and fix the names ASAP so you don't have to guess at which label goes with which active control.
After that, if there is any chance that at a future time your DB might have to migrate to something a smidge larger (like MySQL or SQL Server
), NEVER EVER use _ (underscore) or blanks in object names at any level - whether in tables, fields, or other places. Just break that bad habit BEFORE it starts. Even if you never migrate, it was a bad habit that you should never get into.
A really big GOTCHA that often comes up to tweak your nose and give you a headache is use of a reserved word as a variable or object name. Find the list of reserved words. Print out the list. Avoid using those names for any purpose other than that for which they were reserved. Save yourself so much grief that you won't
believe how bad it can get.
Now, I'll get even wilder. Who gives a flyin' fiddle-dee-dee about what you named anything? Six months from now, you'll have forgotten your names anyway because you were totally immersed in something else. We are creatures of habit. We focus on problems of the day. So to fight this (very natural) tendency, make lists. Use paper printouts to hold your lists. Remember, paper has a better memory than people. Also better in some ways than computers, since you can't pull the plug on a piece of paper and have it do a memory dump. Use the built-in documenter (Tools >> Analyze >> Documenter) every so often. Make updates of your object lists at every level for every object you create.
When you find yourself writing anything, make HEAVY use of any available documentation fields, comment fields, tool-tip fields, etc, as mnemonic devices to help you remember what something is or means. In VBA code, you need to learn how to COMMENT things. In other items, like field defs in a table, you can comment field usage in the DESCRIPTION column. You can add information in object properties. On category panes (tables, queries, forms, etc....) you can right-click on any object and can then enter a description of it. Get used to doing that. The cost is trivial compared to the headaches you will head off later.
