plog's first two sentences pretty much summarize my viewpoint.
I used this convention:
tXXX = a table, linked to a BE file
tlXXX = a local table residing in the FE file acting as a temporary
qtXXX = a single-table query based on tXXX (and there is a good reason to have one of these having to do with what happens when a form tries to directly access a linked table)
qtlXXX = a single-table query based on a tlXXX table
but... qXXXjYYY was a JOIN based on tXXX and tYYY.
Most forms were just XXX, no "f" prefix. On the other hand, subforms were sbfXXX.
Reports were rptXXX IF the report was launched implicitly; otherwise, just the report name.
I didn't use macros so had no name for them.
Code was ALWAYS just the name of the module, no special prefix; ditto, the entry point names. PUBLIC CONSTANT values had prefixes related to their usage, as for example clrXXX constants for a specifically named color that wasn't vbRed or vbGreen, etc.
The point? I stuck to this convention - and it WAS a convention - because it WORKED FOR ME. Didn't care a whistle whether anyone else liked it.
Here's the payoff. For a little project with a couple of forms and five or six tables and maybe twenty queries, it almost doesn't matter what you do. But the more code you have, the more tables you have, and the more queries you have, the worse it will be to try to keep things straight. And THAT is where conventions pay off.
My project probably exceeded 50 tables and 200 queries, maybe about 70 forms (some of which were dedicated to single-entity table maintenance, the rest were the work-horse forms), maybe about 70 to 100 reports, and not less than 12 modules with anywhere from 500 to 1500 lines of code per module. When you get that big, you need to use conventions because it is too big to keep entirely in your head. The names start to blur together. THAT is when having a convention and sticking to it will pay off.
But as plog said,
My advice is to aim for consistency in which ever method you use.
