I Hate Hungarian Notation (in the context of VS.NET, which is where I live)

[jmcilhinney]

Edit: Let me restate my position as I should have in the first place.

I displike Hungarian notation. I don't think that it serves a purpose in a modern IDE like Visual Studio.NET. The benefits it was created to provide matter much less and it creates other issues, therefore I believe that it hinders more than it helps. The way it is used by many doesn't even provide the function for which it was created, with the overuse of prefixes like "obj". Personally, I don't think developers using an IDE with the functionality of Visual Studio or equivalent should use it.

Here is an explanation of what Hungarian notation is for those who don't know.

[Kasracer]

I hate it as well

[RobDog888]

For VB6 and berfore it was great but, like you say, for .NET there are just too many type to make it helpful with a 3 character prefix identification. I think for the most used types that are the same as VB6 had, except for obj which is useless in .NET, its still helpful . You can use it for most but for the rest it just makes sense to do it some other way or drop it.

You dont have an option for "Use it but in moderation only" or something like that.

[RobDog888]

I'm not man enough to make a decision.

So that is why you needed to make a poll

I'm just saying that you could use it for strings with "str" and all the other widely know/used notations. The "new" types in .net could be just be identified with extra long variable names. I hate seeing super long variable names in other peoples code as it makes the code to wide and necessary to be scrolled. I mean come on do you really need a descriptive variable name object like "OLEDBDatasetEmployeeTimeDetail" dataset!

[RhinoBull]

I don't see any point in this poll: if you hate something then DON'T USE IT. As simple as that.

[Shuja Ali]

I hate them too.

How about Camel Casing?

[RobDog888]

Whats Camel Casing? Is that where you hire a Camel to case a place for a potential heist?

[Shuja Ali]

Whats Camel Casing? Is that where you hire a Camel to case a place for a potential heist?

It is the place where Variable/Object names look like Camels.

[RobDog888]

No, but seriously I havent herd about camel casing.

[Shuja Ali]

No, but seriously I havent herd about camel casing.

Came Casing is a younger brother of Pascal Casing.

WikiPedia is where you will understand it

[RobDog888]

Thanks. I use a hybred of hungry notation and camelcasing and never knew it.

Dim strUserName As String

I'll call it HungryCamelNotation.

[sevenhalo]

I like it. One, it's familiar (coming from the legacy VB background and the little C++ and pascal I did). Two, I don't use my mouse alot when I code; so mousing over things is a nuissance for me. When I'm coding along and my strings all have str infront of them; it keeps their datatypes in the back of my mind. That way, without going back up to check the type or letting intellisense blow a gasket about Option Strict, I can Convert as I go without an extra thought.

Plus, I'm a tyrrant when it comes to standards. I'll keep socks in my pants drawer and put peanut butter in the bread drawer, but so help my god... If my reference and data types aren't divided by region and groupped together... I will trash the code and start from scratch without a second glance. When declarations aren't clean and spiffy, its the biggest sign the code you're working with is bandaided and you just "changed things until it worked."

The things you're proud of and put alot of effort into are the things you take care of. If you won't clean your code, group your declarations and indent it; you're obviously not proud of it. Hungarian notation is a sign of cleanliness to me. It means you had a direction in the start and ended facing the same way. And chances are, you won't see objects named tempHold or test1, test2, test3....

[Shaggy Hiker]

I find it hard to read, but I must confess that I do wart some of my variables, too.

[Shuja Ali]

I like it this way.
sFileName
s -- stands for string
FileName - the name of the var

iFileNumber
lPostCounter
dMySalary
oFile

I find it easier to write just one letter instead of writing 3 letter for string, etc.

[RobDog888]

I have been doing it that way for years. Only started posting "str" or 3 letters just for the forums a short while ago. The shorter the better but as long as its still obvious of what type the var is.

[gigemboy]

Well camelcasing (or putting at least one capital in the variable) is handy so you know if you are typing the right variable in the first place. If its recognized and you move onto a new line in the IDE, the variable will switch case telling you that you typed it in right and it is located somewhere. If you type in a variable, move onto a new line and it is still all lowercase, you know that you typed something in wrong...

[Shuja Ali]

Well camelcasing (or putting at least one capital in the variable) is handy so you know if you are typing the right variable in the first place. If its recognized and you move onto a new line in the IDE, the variable will switch case telling you that you typed it in right and it is located somewhere. If you type in a variable, move onto a new line and it is still all lowercase, you know that you typed something in wrong...

Thats a good logic there.

[RobDog888]

Yes, but that doesnt apply to C# though.

[Shuja Ali]

Yes, but that doesnt apply to C# though.

It actually does. If you try to use a wrong variable name it will be underlined.

[RobDog888]

True but it wont automatically correct the casing is more of what I meant.

[Shuja Ali]

Life in C# is not as easy as VB.

[RobDog888]

Life in any of the .NET languages is not as easy as VB ever was.

[RobDog888]

All your doing is using hungrynotation in action type rather then just the plain description.

is = boolean
? = string
? stream

'...

[RobDog888]

the name of the variable should describe the value that that variable contains, not its type specifically.

So then isComplete could carry a value of "Yes, No, True, False" all of which are basically a boolean.

But your also saying that the name of the variable would describe what it contains which is also its data type

[penagate]

I can't stand Hungarian notation, it makes code unreadable and does not help at all, if you name variables logically and descriptively then you can infer what the type of the object is anyway; as if it's even all that important, it's much more help to know what the variable's for, which Hungarian does not help at all with. If a trivial change is made like changing the type of a variable from int to short then you shouldn't have to change its name because the name should have nothing to do with it.

I use the Java notation which is the lowercased form of CamelCasing
e.g.

thisIsAVariableName

As a side note for all those of you talking about mousing over variables and IDE's capitalising variable names for you, this is a test to see whether your coding style is logical or not. Code everything 100% in Notepad (or an editor with syntax highlighting at most). See if you can understand what's going on and write neat maintainable code, without all the flashy gimmicks that an IDE provides. If you rely on the IDE to understand your code, you are seriously hampering your productivity. I never use IDE's any more (except for C++ where it does help me learn).

Edit: MSDN, as of .NET, also discourages the use of Hungarian notation.

[RobDog888]

@ the MSDN comment is because its not called Microsoft notation.

"thisIsAVariableName" is terrible as it doesnt use hungrynotation nor does it tell what the variable is used for.

VB6:
rsEmployees says its a recordset object and is also descriptive for the information being held in the recordset.

[penagate]

One situation where I can see an obvious potential use for it is in a weak-typing situation, such as script languages. But then again, the same principle applies. As John said, name your variables descriptively. And my addition: If you can figure out how a variable should be used, it doesn't matter its type. You might have a custom class that behaves like a numeric data type, well then use it as you would a numeric type. You shouldn't have to use its name to explicitly distinguish between your custom object and a built in type; that just makes data typing get in the way of programming logic.

As for the rsEmployees example - sure, it helps a lot in an isolated situation. But you never see variable names in isolated situations, you seem them in their own context in the code.

Now some real world examples of variable names (these are from PHP, a weakly-typed language, so you'd think having the data type in the variable name would be even more important)

function BBToXHTML($code, $parseURLs, $allowLocals) 

The function is used to converting BB code into markup. The parameters are obvious - $code is the string containing BB code, and the other two are booleans affecting some processes. How else could you interpret it?

function Connect($db)
{
  $this->_conn = mysql_connect(Database::_HOST, DB_PREFIX.Database::_USER, Database::_PASS);
  mysql_select_db(DB_PREFIX.$db, $this->_conn);
} 

Again, it should be obvious to anyone with a bit of background PHP knowledge. _conn - a local variable holding the mySQL connection reference. _HOST, _USER, _PASS - all local constants (the capitalisation of constants is I think a K&R convention, from C). $db contains the database name to select. I have also used $db to hold a database wrapper class object (for things like $db->query(), etc.), but it HAS to be a string in this context. There's no ambiguity.

[RobDog888]

I think its harder for John to see where the most of us are coming from on why we like hungry notation, a vb6 background. For programmers that are diving straight into vb.net they will feel likeits useless.

employeeRecords is a good name and sure there is a good point being made with it but I personally dont like longer then needed variable names.

[penagate]

I wouldn't go so far as to not use an IDE because they are great tools and they make you more productive. I drive a car but if my car breaks down I still know how to walk.

Exactly. IDEs help a lot and when used correctly they can vastly improve your productivity. However if you rely upon them completely rather than just using them as tools it does restrict your abilities.

[RobDog888]

So I guess thats why I dont walk anywhere. I'd rather stay home then walk

[penagate]

I think its harder for John to see where the most of us are coming from on why we like hungry notation, a vb6 background.

Explain me then, I spent 7 years coding VB6, it was my first programming language and I used Hungarian all the time because that's what books and tutorials told me to do. Recently I made the decision to abandon it for all languages including VB6, and when I went back to code that used it I just thought "Wow that is pointless".

So I guess thats why I dont walk anywhere. I'd rather stay home then walk

Me too it's boiling outside :-P

[RobDog888]

But my point is that your also coding in .NET where all this is more relevant and meaningful. If you were still a vb6 coder you would think its great and still needed.

I still cant get out of the habit but in my vb6 apps I still use it and in my .net apps I am slowly getting away from it because of the points made by John.

[si_the_geek]

For .Net (from what little I've seen) Hungarian is pointless.

For VB6 it works well, but I prefer a different naming scheme that I picked up on a particular job, which makes typing variables in VB6 so much simpler,
eg: vm_UserName_str

Where V is Variable/Const/Static/Parameter,
M is Module/Local/Friend/Global (public would be better, but Global was what I got used to),
Str is an abbreviated variable type, but as you say this only works with a limited number of types. (if the type changes, Find & Replace only takes a second!)

[Shuja Ali]

I can see people love Camel Casing too.

[RhinoBull]

I can't stand Hungarian notation, it makes code unreadable ...

I won't be trying to dispute what we like/dislike but rather ask you how can you find intIndex to be NOT readable when it clearly stands for an Integer type or lngIndex - for a Long ??? I just don't understand your comments pen at all ... I can see a bit of confusion when it comes to String vs Stream but for the sake of truth Stream object didn't even exist in wildest dream when this syntax was developed. Common really guys - it's really getting silly to read all of the complaints - don't use it. Use whatever the heck you like but think about those that will come after you to support your piece of art.

Cheers all.

[Shuja Ali]

Use whatever the heck you like but think about those that will come after you to support your piece of art.

Very well said Rhino

[Hack]

I won't be trying to dispute what we like/dislike but rather ask you how can you find intIndex to be NOT readable when it clearly stands for an Integer type or lngIndex - for a Long ??? I just don't understand your comments pen at all ... I can see a bit of confusion when it comes to String vs Stream but for the sake of truth Stream object didn't even exist in wildest dream when this syntax was developed. Common really guys - it's really getting silly to read all of the complaints - don't use it. Use whatever the heck you like but think about those that will come after you to support your piece of art.

Cheers all.

What he said!

[Shaggy Hiker]

So I guess thats why I dont walk anywhere. I'd rather stay home then walk

I am utterly opposed to this statement

There have been many good points made in this thread. I remember reading an article in C/C++ Users Journal a few years back that ripped apart Hungarian notation for C++ because it was unworkable beyond a limited subset of objects. I forget pretty much all of the article other than that they showed how even MS was not internally consistent (and could never be) with their use of warting.

Therefore, the arguments made here have been hashed out in published articles for years. There are two camps, those who love it, and those who hate it. Hardly surprising that representatives of the camps are to be found here.

[RhinoBull]

...I believe that people should use what they want too. ...

It's obvious that you haven't worked for some major corp were coding rules are very strictly enforced and people are getting fired for not following. Whether you like it or not is not the point - it's a work discipline wich quite often plays major role in a team environment. If you feel like you don't fit in it then you must go but never suggest that what you dislike is a bad habbit.

I wish this thread would be closed - very much pointless gossip.

[szlamany]

I read some early posts - hard to digest this whole thread...

In a shop where more than one programmer touches the same code having conventions is how the group survives - no - actually thrives!

If the shop conventions are to have hungarian notation to assist in "shared development" - then that's a good thing. It cannot be disparaged.

We force our "coders" to name parameters in SPROCS to actually match the "case context" of column names. If the column is StartDate - then the parameter must be @StartDate.

Failure to do this will cause the client app to not bind to the parameter at runtime. This might be considered over-the-top - but we derive the "tooltiptext" for the "object" names. And if sloppy coders were allowed to say @startdate or @STARTDATE then the final product who not be consistent or professional.

lngXXX and intXXX might be more than some want to do. But frmFormName and txtSomeTextBox or txtStartDate allow for easy grouping and easy recognition of objects at design time, enhancement time and forever.

We also allow i, j, k and x, y and z as "standard" conventions for "simple" long variables. We all know that i is long. We also allow s1, s2, s3, s4 and so on as "standards" for strings - we all know this - so it's as good as strText.

If the variable is going to have "more life" in the code then a one or two lines then it needs to be named more clearly.

25 years of coding with others and leading R&D teams has led to strong conventions in my shop.