I like to read Joel on Software. I don’t know if he’s smart, but I know he’s smarter than me. Recently, I enjoyed reading Making Wrong Code Look Wrong. I’ve long disliked hungarian notation, or what I now know as Systems Hungarian. The reason that I dislike it is because it doesn’t serve any purpose to me, almost. I know that Fname is a file name and thus a string. sFname doesn’t help. I know that Idx is and counter in a loop and thus a long integer. lIdx doesn’t help.
All my code, both the code I publish here and the code I don’t, uses Systems Hungarian. Why? I don’t know, but I suspect it’s a combination of a lack of a better alternative and my conformist personality. It costs me virtually nothing to use sFname instead of just Fname, and if it helps just one person understand the code more easily, then it’s worth it. However, if there was a better way, I think I would latch on to it, so long as I could understand it.
I was writing a function for the Tenth Hole Tracker and I started with the key field of the Players table being a string, namely the players’ names. After some soul searching, I changed the key field to a meaningless autonumber (a long integer). While I was building my WHERE clauses, I used variables like
Now I had to change all the code to something like
It was quite helpful to have the ‘s’ in front to remind me to remove the single quotes. If the variable had been simply Player, then I wouldn’t have had that visual clue that I needed or didn’t need to enclose it in quotes. Had it been one function, it may not have been a big deal. By the time I had my epiphany, I had no less than seven functions that needed to be changed. (I shouldn’t be builing so many SQL statements, probably, but I’ll save that for another
There is, what I consider to be, a good example of why Systems Hungarian is a good system. Knowing that my variable had to match the data type in the database, it was useful to have the data type prefix. Joel gives a pretty good example of Apps Hungarian with his signed v. unsigned strings. I get the example, but I’ve never seen it in practice. Maybe my apps aren’t complicated enough to warrant a different notation system.
Okay, enough of my drunken ramblings. The whole reason for this post is to hear what you do. Are you a strict Hungarian Notator? Have you ever used a system that wasn’t data type based? Do you sometimes deviate and in what situations? Discuss.
18 thoughts on “Hungarian Notation”
So what are the Systems Hungarian for Excel related objects?
So far I would use:
ws = worksheet
wb = workbook
rng = range
I started using the three letter prefixes (e.g. strFileName) when I started out so that I could pass myself off as a VBA6 programmer. I still do it for VBA6 code even though I’ve grown to hate it. Am I correct in thinking there has since been a move to single letter prefixes (e.g. sFileName) or did I just get my initial analysis wrong?
I used to employ a single ‘o’ prefix for my custom class objects and still use a ‘C’ prefix for my objects (e.g. Dim oTable As CTable). I’ve now dropped the ‘o’ in preference of more logical variable names (e.g. tempTable) but I’m still stuck with the ‘C’ which gets annoying e.g. this from the Immediate Window
Set f = CreateObject(“SafeArrayViewer.CViewer”) : _
The ‘C’ prefix just seems so unnecessary in this context.
In .NET code, everything is an object so I’ve dropped all prefixes. In VBA6 I never use prefixes for parameters (unless I need a quick way to circumvent the ByVal Table As Table problem) but in .NET I use camelCase for parameters because that’s the convention. So am I avoiding prefixes in .NET because it’s the convention?
Dick: I try to adhere to that as well. But only very recently I have started adding scope prefixes as wel, e.g. g for public (global) variables:
Public gsPath as String ‘Holds the path the utility writes to
Nick: I think there isn’t an exact rule that determines what to do with object variables. I tend to simply use the letter “o” as their prefix and then ensure the name itself gives a clue about the object:
Dim oSourceRange as Range
Dim oSourceSheet as Worksheet
When naming objects directly (e.g. controls) I use three letter prefixes for the object names, tbx for textbox, lbx for listbox, etc.
I try to use prefix that catch the scoope of general variables and as for Excel I use wb, ws, rn etc as prefix to objects in Excel’s object-model.
I believe we all use a personal style, more or less, and it will propably need a headshrinker to figure out why we use the style we do ;)
In VB.NET we are recommended to *not* use any prefix at all.
I used to use John Walkenbach’s unfettered approach to variable names, but I’ve learned that those few keystrokes really can be helpful.
I don’t go too overboard with the prefixes, though I do use a shorthand to try to remind me what could I have possibly been thinking when I wrote that code. s for string, r for range, i-j-k-l for int or long (often i for row and j for column), the obvious wb and ws. o seems like a cop out for object names, but I don’t use too many generic objects. v for variant, va if it’s an array. I’ve found m and g to be helpful to remind me of the scope of the variable. I use F and C for the for or class and frm and cls for the specific instances, but I usually avoid prefixes for the property names.
The important thing is the root of the name, which helps when reading the code, especially weeks or months later.
When writing PED, Rob and I had some lengthy discussions about what to use. We agreed that the key points are to be consistent and practical. There’s little point in creating acronyms for every single data or object type you’ll ever use. As Joel suggests and Dick has discovered, the reason for doing it at all is to make code easier to understand and thereby (hopefully) easier to identify errors. So object and data types that are used a lot tend to get a type prefix, such as wkb, wks, rng etc, but I quickly just use an ‘o’ for most other objects – particularly so if there’s little chance for ambiguity in its use. If I ever declare an object ‘As Object’ rather than as a specific type, I always give it an ‘obj’ prefix. When I see that prefix in the code, I know that the object hasn’t been compile-checked for syntax, spelling etc. and so I have to be much more careful.
When writing classes and forms, I tend to use a grammatical convention, where I use nouns for the class names, adjectives for the properties and verbs for the functions and subs. The only time I use prefixes for classes is when I’m creating a multi-tier architecture, where I’ll use BClass for the business tier, DClass for the data tier, UClass for the UI tier etc. Doing so lets me easily see if I’m (wrongly) mixing objects from different tiers.
I only use Hungarian Notation when writing C/C++. When I’m writing in Excel VBA (as most people who read this blog do) I use RVBA Code Conventions. It is more of a standard for VBA code than Hugarian Notation. Almost all RVBA tags are 3 charcters. For example:
I also use this same style for all my VB code whether it be VBA, VB6, VB.Net, or VBScript. I personally really like it.
This poorly written website is what I use as an RVBA quick reference. I’m sure there are much better sites out there:
I guess my Polish heritage prevents me from using Systems Hungarian. (Don’t even think about asking what Systems Polish would look like)
Standards I like:
X for arrays: Ax, Bx, ProjX
xc for Collections: xcProj, xcA
rng for range objects: ProjRng
i,j,k: obligatory longs for loop inicies
rrow, ccol: longs for range object indicies
g-prefix for global variables (I don’t fuss with m for module level variables)
I also like to set sheet codenames like “ProjSht”, because the VBA reference also has an implied “Thisworkbook” in the sheet codename.
For naming sheet tabs I use a convention of “&sheetname” for hidden sheets, so a quick routine can hide and unhide them by identifying the ‘&’ character.
Can you tell I work with projects alot?
I use Hungarian in almost all of my code. I feel it helps me keep my thinking straight – especially in Excel VBA where so many things can be referred to by name/number or as objects.
DataSheet could be a sheet name, or a reference to a sheet – strDataSheet or wsData is so much clearer. Same with InputRange (better: either rngInput or strInputRange) or LastRow (better: lngLastRow or rngLastRow).
I’ve used the RVBA convention consistently for years. Part of it’s habit, but I do think there are some other good reasons to stick with it. For example, you’re virtually guaranteed that any variable name you choose will not also be the name of a VBA keyword or an object on a form or in your document.
Probably the biggest reason I use the convention in VBA and miss it in VB.NET is that I teach people how to program. I’ve found that beginners have a lot of trouble keeping all the different objects and variables straight, and it helps immensely when they can see a pattern in the names you use.
Microsoft doesn’t allow use of Hungarian in samples and whitepapers written for VB.NET and C#; I think in the long run this makes sample code of any length more difficult to read and understand, and I’ve found that I end up adding something to the names of objects to tell the reader what the object is (for example, custIDComboBox). I’ve seen this done in samples written by other authors as well. Too bad; that’s a lot more typing to get the same result.
Like a previous poster, I also use RVBA notation. The notation is just easier to read. Beleive it or not, in Access I attempted to use integer prefixes for my objects to keep like objects together in the listings. We’ll try anything, once.
I go RVBA myself. And I am anal-retentive about using this along with a meaningful variable name. I refuse to debug others work (here at the office) if they use variables like x, i, abbreviations or acronyms. I find it saves time when your code reads like english instead of like wierd algebraic equations. I have never handed code to someone else and have them ask me what the heck it means. As an aside I also comment the heck out of things.
After reading all the links, I have some thinking to do. I like the premise of having wrong code look wrong. Having written code (which for me, I read it first) in several languages, I have always argued about defining and using descriptive constant names instead of values in your code.
When it came to variable names, I want to know what they are. In Cobol, yes Cobol, the variable declaration was no big deal, add a PIC X to a Pic 9 equals an OC7. With today’s environment, you can avoid this protection during run time and have the environment guess what you wanted and then see it do it.
As far as C and Basic, I don’t think I need to know what type variable is. I need to know what it is used for. It’s up to me to know how it’s defined and to keep it as local as possible.
I prefer functions that return a result. Then, have the calling routine use the result. Otherwise, a change to the variable value is harder to track down.
I am going to sit down and try to understand the Apps Hungarian and see if I can convert my code from System Hungarian. The overriding determination will be if I can achieve, like Bullen, Bovey and Green say in PED, that the result is “consistent” and my use a new convention afterwards can be too.
I try to use the Hungarian notation whenever possible and I’m Hungarian. Does that qualify as a valid comment? :-)
JP: “I usually avoid prefixes for the property names”
A general appeal: avoid any notation in property/method names and their parameters. Put another way, how would you like it if you had write client code like this:
gclsExcel.oApplication.colSheets(varIndex:=”Sheet1?).oRange(strCell1:=”A1?).varValue = “groan”
Aside: is it just me that has a problem with variable names such as
Private mintCondition As Integer
One I often use:
Dim oSht As Worksheet
Dim oCanada As Anthem
i often use
Dim bytCounter as byte
Dim lngCounter as long
because of prefix , in between of code i know its a byte type counter and i will not use it in a loop more then byte limit
Posting code? Use <pre> tags for VBA and <code> tags for inline.