I've come to take exceptions to some of the advice from the "style" experts. Yes, writing one long line of clever code is... um dumb. There's some I still haven't figured out how they work, despite being quite elegant. I chalk it up to lack of time, reason to know or ability.

Years ago, a style for naming variables in VBA was proposed by two guys, Leszynski and Reddick, if I remember correctly. They proposed something similar to one my professors some two decades earlier. However, another professor who had lots of experience with code (before the 1970s) balked at my code saying "You don't need to know this is an integer, that's why we declare it above, you're much better served by a few letters that serve to explain HOW the variable is being used."

For example, we could  say "Customer" but if you name it "tblCustomer" doesn't that eliminate a lot of confusion? That's a valid use of a prefix to me, but saying strName means what exactly? Clearly a name isn't going to be a decimal typed variable.

I use "w" to indicate "work", as in I'm building a variable to do something, not just data pulled from a table. For example, wCustNameFull tells me that I'm doing something (probably concatenation with trimming) to stick all the parts of a name together from different fields. Likewise, I tend to use an "a" in front of a variable to indicate this was an argument passed to the procedure (via a parameter). Instantly I know the data came from some other procedure and that I better not mess with it. If I see something that be like a variable in my code, but it starts with a "f" or "s" then I know immediately that it's a function or subroutine, and not a variable. The end.

Simple Code over clever code every time.

Yeah, I've never really needed prefixes on any of my variable names because most of them are obvious and straightforward, like you said: FirstName, LastName, CreditLimit, those kinds of things. The main reason why I started putting T, Q, F, and R on the end of my Access objects like CustomerT, is because way back in the day, whenever you were using a wizard to try to create a combo box, for example, and it asked you where you wanted to get your data from, it didn't separate them into tables and queries. So if you had a table named Customer and a query named Customer, you were shit out of luck, LOL.

So that habit stuck, but it's also nice because sometimes when you're dealing with record sets or more advanced objects, it's handy to know whether the data source is coming from a table or query. It's also nice at a glance when you're looking at form properties. So I'll be keeping that habit, and I'll still teach that in the future because I think it's handy. But as far as true Hungarian notation for variable names, I've never needed that stuff, and I build some pretty elaborate programs.

Richard, I suspect you probably meant "if you had a table named Customer and a query named Customer, you were..."

You are correct. Edited. Thanks.