I hinted at this during the Excel user conf the other week when I asked who used a naming convention in their Exccel VBA.
I am being very specific about what I am talking about – VBA code that sits in a spreadsheet or add-in in some business type application. Not C systems code.
Some authors suggest using a 3 letter prefix to signify the data type of a variable
Dim x as integer becomes
Dim intx as integer
I used to do this because I thought it made my code look ‘more professional’, harder to read, but ‘more professional looking’. Then I read this, which totally cleared up why I didn’t like data type prefixing.
And then I read Code Complete by Steve McConnell.
Around the turn of the century Microsoft released their naming convention advice for .net (ie – business applications), which built on advice from MFC era in the ’90’s. (note the advice ‘Do not use Hungarian notation’ here)
My advice is simple, and here (near the bottom) – basically just choose a good meaningful name. That presupposes other things like general design, procedure length etc are sensible.
I think, like in many things, if something works for you, then great, use it, if it doesn’t then don’t.
Just in case you didn’t know the VBAIDE has had the locals window feature since the last millennium:
(You will notice I havent discussed scope prefixes – I find them quite useful if I have to use non proc level variables)
As it happens I do use frm, qry etc in Access, but hey maybe thats just another habit I need to kick. Well, and hands up, I still often use a single letter data prefix, (s, l, d, r, etc).
So, do you use data type prefixes? If so why?
Do you use ‘Original Hungarian’ – where the prefix indicates the usage, rather than the somewhat less valuable underlying datatype?
Do you still use the ‘my’ prefix so beloved in MS VBA documentation (myString, myVariant, etc)? (‘my’ as opposed to whose??)
Do you use carefully thought out, clear unambigous names?
Do you just type any old stuff in to get the thing to run?
(I do all of the above!)