Struggling not to use Hungarian notation

Question

I've seen arguments for and against Systems Hungarian. For some years I've been working on a legacy project that uses this system by naming every variable, function with a prefix of the variable type eg (strName, intAge, btnSubmit etc) (I know the original Hungarian Apps prefixes by the kind of variable, not the type). I'd like my next project to abandon it fully, but I do find it harder to name similar things uniquely without resorting to it.

Lets say I have an webform for collecting email addresses and storing them in a database table, and button which calls the function which save the address to the db.

If I'm using Hungarian style notation, I might call the box txtEmail the button btnEmail and the value contained in the textbox strEmail. I might then use a function storeEmail(strEmail) to store the email. I have a clear convention here, it's obvious what each variable is.

What would be the best practice for naming these variables

• without resorting to Hungarian Systems,
• without making them over long or confusing
• and with a clear convention to use across the whole of my project?

• user7043: Perhaps there's something wrong with the rest of your naming conventions, or the size of your functions, if you have trouble finding unique names.
• StuperUser: What technology are you using? These prefixes seem to lend themselves to Web Forms.
• fearoffours: I'm using ASP.NET (with C# behind)
• fearoffours: @delnan - can you elaborate please? Why does function size make naming uniquely easier?
• user7043: @fearofours: A smaller function needs less variables, and less variables obviously mean less variable clashes. That assumes of course you put every variable in the smallest possible scope.

Answer 1

Your last point is the most important - whatever you do you need to be consistent across your project and with your colleagues. There are two main ways to acheive consistency and if possible you should use both. Firstly use a tool to check naming conventions at build time. In the .Net world StyleCop would be a good example of such a tool. The second way to get consistency is to have peer reviews of all code, so that you can all keep a look out.

Your other two points seem to be asking about an alternative. I'm not sure you need an alternative; the point about Hungarian no longer being popular is that it used to be used to descibe the type when the type system and tools were a bit, shall we say, less strict. I.e. if you were programing in C and passing pointers around the only way to keep track of the type was by using Hungarian. Now, if you are using a language like C# or Java you will not be using pointers (or very rarely), so the need for any kind of Hungarian goes away. Also, modern IDEs let you see the type very easily by hovering over the variable or at worst using some short cut to see the original declaration. So, I don't think you need any kind of notation, just name the variable by what it does. If it's an email address just use "email" or "emailAddress". If it's a customer name just use "customerName" etc.

• FrustratedWithFormsDesigner: It gets a little trickier when the form/page/window/whatever has a button for email, a text box for email, and maybe another widget/control for email...
• Jonathan: @FrustratedWithFormsDesigner Not necessarily. The text box could be emailAddressInput where as the button be emailAddressSubmit and the internal representation be simply emailAddress.
• FrustratedWithFormsDesigner: @Jonathan: Good point.

Answer 2

When dealing with web forms / Windows forms / other graphical stuff, it makes sense to use Systems Hungarian since you can have controls that are very tightly tied together—for instance, a text box and a label that go together; you might name them txtEmail and lblEmail to distinguish them. In my experience, this is common and is actually useful.

But in your code-behind, this kind of naming is unnecessary. If you have a variable of type string that is being used to store an email, just name it email. If, for some reason, you get confused, most IDEs should allow you to hover over it and see its type. (Ideally, in OO stuff, it might be an attribute of some object, and user.Email is even more clear.)

I think if you have more than one object being declared in your code that isn't a GUI control that could be rightfully named email, something is inherently wrong with your design.

• Steve: Actualy txt and lbl are not Hungarian, txt is just short fo Text and lbl short for Label, there is no reason not to just use the full length word e.g. EmailText and EmailLabel on a form. Hungarian would be the type, which in both of these cases is a string.
• Andrew: @Steve Haigh - No, I'm talking about the controls themselves. You have an object of type "textbox" called txtEmail, and an object of type "label" called lblEmail. Neither of them are strings. They may have string properties, but they are not strings themselves.
• Steve: Ah, sorry. Yes of course. Even so, there is no reason not to use a more descriptive name such as EmailTextBox. Just because VS generates a poor name doesn't mean you have to keep it. However, in the context of forms, the txt and lbl abbreviations are so well understood I would probably not worry in that case.

Answer 3

What makes a variable "over long"?

Instead of txtEmail, btnEmail you could use UserEmailText, UserEmailButton, and AdminEmailText, AdminEmailButton

The issue with this is you might start feeling that the variable starts to get long:

AdminEmailIsValid starts to borderline on how long I'd allow the variable to be.

Additionally, you might start noticing that you're reusing a set of variables, and a set of operations on those variables. This is what OOP is designed for. Instead of a set of variables, create a generic object:

class EmailForm
 var textBox, button, text
 function storeEmail()

Then you can instantiate a new variable as a class, and use the same dot notation to access your data:

userEmailForm = new EmailForm(...data...)
adminEmailForm = new EmailForm(...different data...)
doSomething( userEmailForm.text )
doSomethingElse( adminEmailForm.text )

Of course, this is targeted towards languages which use the OOP paradigm, but the majority of popular web development languages are object-oriented, or allow for object-oriented code (PHP, Python, C#, C++, Java, JavaScript, ActionScript, etc).

• fearoffours: I fail to see the advantage of UserEmailText to txtEmail - you're just suffixing the type rather than prefixing it. I like "This is what OOP is designed for", though.
• zzzzBov: @fearoffours, OP admitted to having an issue with unique names, I added that example as a descriptive way of distinguishing between two similar variables (UserEmailText and AdminEmailText specifically). I usually suffix types as it lends itself to moving to a class UserEmailText -> UserEmail.text -> User.email.text depending on how much abstraction/functionality is necessary.
• fearoffours: OK see where you're coming from there. +1 for the comparison of suffix/ class. Oh, and I am the OP!
• zzzzBov: @fearoffours, lol whoops...