in Search
Welcome to Neopoleon - Sign in | Join | Help
Navigation: Home | Forums | Galleries

Die, Hungarian notation... Just *die*.

Something I haven't mentioned yet on the blog is that I'm writing a book. I don't know how much I'm allowed to say, so I won't discuss the topic or the publisher, but what I will say is that I've been doing a lot of research for it. I've been reading bits of books, tons of articles, and whatever I can find in the blogs.

What I've decided is this: Magazines should no longer take submissions from authors who don't write their code according to the Microsoft style guidelines.

I've especially grown tired of Hungarian notation. If I see one more cryptic made-up-on-the-spot prefix like "dgrd," I'm going to go nuts(er). I don't understand why, in this day and age of the superpowered IDE, people still think that they need to express their object's type in the variable name. It's just dumb.

People have argued with me about this by saying something along the lines of, "Yeah, but there's so much code in my method that I need to keep track of my object types like that."

Well, well, well. I feel sorry for the poor bastard who's going to have to maintain that code. If your method bodies are so bloody large and complex that you've lost track of what your objects are, then you deserve to feel confused.

My favorite, though, is "o." Nothing is better than an "o."

"oMyObject"

"oWordObject"

"oMyGodI'mGoingToLoseIt"

I mean, it wasn't already obvious to me that it was an object. It only derives from SYSTEM.I.AM.A.BLOODY.OBJECT.LIKE.EVERY.OTHER.DAMN.THING.IN.TOWN.

Hungarian is perfectly all right if that's what your company requires, or if that's the sort of sick thing you like to do with the blinds drawn late at night. But, and I'm saying this in the nicest way possible, take that Hungarian notation and shove it.

The world would be a much better place if we all conformed to one set of style guidelines. When we inherit each other's code, as inevitably happens, we wouldn't have to squint and turn the monitor sideways to understand what someone was trying to do.

The best code isn't just about function - style is much more important than most developers realize.

[Update: If you're looking to change your ways and bring your code into the 21st century without a time machine, then this is a good place to start.]

After Blog Mint [?] :

Sometimes I think I should have have just been a corrupt shrink.

Published Tuesday, June 01, 2004 8:43 PM by Rory

Filed Under:

Comments

 

Matthew Burns said:

ok I'm sold.

got a good link for Microsofts Guidelines?
June 1, 2004 8:49 PM
 

Rory said:

Hey, Matthew -

I've added a link in the post. I should have put one in there to begin with, so thanks for bringing it up :)
June 1, 2004 9:07 PM
 

Russell Kellly said:

Rory,

You are completely right. However, where I work we have people that are just coming out of the Cobol/MUMS fog and into the new and marvelous world of .NET. So having them learn object oriented programming and a new way of naming variables, I am afraid their heads will blow up. We ended up adopting what PSDA.com has published for programming standards.
June 1, 2004 9:16 PM
 

Jason Bunting said:

Amen brother, preach it!!! I was just thinking this today as I was watching some how-to video and two days ago as I read an article in Visual Studio magazine.

I recently started contract work for a company whose lone developer also does the whole 'o' thing in his methods parameter lists.

public void DoWork(SomeTypeFoobar oSomeTypeFoobar)

ARGH!!!!

Thankfully, he was willing to change - which I doubt happens much . . .

June 1, 2004 9:34 PM
 

Randy Glenn said:

Aaargh... why must everything on MSDN be so hard to print? Structured online docs are great, but I have neither a spare tablet nor a second monitor to read from whilst I code, so a big honkin' pile of deadtree is mighty useful.

What I'd love is a way to say "Turn this section into a PDF" or something, so I can have my docs and use 'em too.

(Please correct me if there's already a way to do this)
June 1, 2004 9:34 PM
 

Jason Bunting said:


BTW, another good set of coding guidelines are those published by Juval Löwy:

http://www.idesign.net/idesign/download/IDesign%20CSharp%20Coding%20Standard.zip

June 1, 2004 9:36 PM
 

Jason Bunting said:


Russell, I think you meant http://www.pdsa.com/

June 1, 2004 9:47 PM
 

Russell Kellly said:

Jason, that is exactly what I meant. Thanks
June 1, 2004 9:53 PM
 

Jason Mauss said:

Rory - what you fail to realize about (or just don't talk about) is that the majority (and I'm pretty sure I'm right by using the word majority) just don't give a sh*t. They'll give their variables stupid names and used retarded prefixes and their lives won't be any different because of it. They'll trudge along for their whole career not caring b/c it doesn't affect what happens at the end of the day. They still get their paycheck and move along. Not enough developers are passionate enough to take real pride in their knowledge/work. Don't ask me how they do it.
June 1, 2004 9:54 PM
 

John said:

I don't believe you can infer from someone using Hungarian notation that they don't care about their code. I would think quite the opposite. They are at least using a coding convention!

Hungarian had its purpose. Sure, the recommendation is not to use it any more, but its hard for some people to drop. If you have been using it for 5+ years, your code looks a little bare when those little helpers are gone.

Whether some source uses or does not use hugarian does not make it significantly simpler, performant or maintainable, it's just the most visible aspect. There are much more important factors that affect code quality.

That said, I agree, people should be weaning off hungarian ;-)
June 1, 2004 10:29 PM
 

Kevin Dente said:

While I don't disagree with you (I was quite happy to ditch Hungarian), I will point out that the MS Style guidelines don't dictate the absence (or presence) of Hungarian notation, or any other coding convention, for the internal implementation of your code - only for the publicly accessible elements of your types (parameter names, property names, etc).

I do find it odd that many .NET developers (including me) are vocally opposed to Hungarian prefixes, and yet many (not me) have adopted the "_" prefix to identify private member variables - which, if you think about it, is a form of Hungarian itself, not much different from "m_".

Anyway, I've been fighting the "no hungarian" fight for .NET code at my company for a while, but some people find it hard to change their old habits. Including, apparently, some MS folks - parts of Rotor contain Hungarian.
June 1, 2004 10:32 PM
 

haacked said:

Although I'm all for phasing out hungarian, I do like the _ modifier (but not the m_ modifier) for private members. It's has a very small visual footprint. You almost can't see the little sucker there. But it really helps in two cases. One, I immediately know its a member var which is a different piece of information than knowing the type (which Hungarian solved back in the day), and two, for constructors it lessens typing so I don't have to do a bunch of <code>this.var = var</code>. Instead we have <code>_var = var</code>
June 1, 2004 10:44 PM
 

Josh Flanagan said:

The "o" prefix is by far the most painful offense. I can "almost" understand when someone uses a "str" prefix or something along those lines, though I wish they wouldn't.

"Yeah, but there's so much code in my method that I need to keep track of my object types like that."

Enter the Code Definition Window in Visual Studio 2005. Have you seen that yet? Wow. No more "Go to Definition" shortcut required. Easily my favorite new feature of the IDE.
June 1, 2004 10:54 PM
 

Chris said:

i use the _ for private members...and when reading this post I realized that I also prefix controls on forms etc. with txt, lbl, cmb, lst, lv etc. I find that quite useful on a crowded form with 10+ controls. Seperating tha lables from the textboxes is just easier that way IMHO.
June 1, 2004 10:57 PM
 

Rory said:

Kevin -

"While I don't disagree with you (I was quite happy to ditch Hungarian), I will point out that the MS Style guidelines don't dictate the absence (or presence) of Hungarian notation, or any other coding convention, for the internal implementation of your code - only for the publicly accessible elements of your types (parameter names, property names, etc)."

That's entirely true - a lot of it really does seem implied, although the reality is that it's much more useful if something is actually written down, so I agree with you.

It's probably my days with Java that got me camel casing all my locals, parameters, etc, and I'm just taking it as a given that other people will migrate their Java habits over.

'Course, one Java habit that I *love* is leaving the curly brace on the line of the declaration/if/whatever. That's the one really sore spot for me, although I'm perfectly willing to do it however anybody wants.

"and yet many (not me) have adopted the '_' prefix to identify private member variables - which, if you think about it, is a form of Hungarian itself, not much different from 'm_'."

I went back and forth a lot about "_" and eventually decided to go without. But I *hate* "m_" - just can't stand it.

U-g-l-y.
June 1, 2004 11:03 PM
 

Kevin Dente said:

Ah, so "_" is OK, but "m_" is not. "txt" is OK, "n" is not. It's a fine line, isn't it?

Incidentally, the most common argument in favor of Hungarian that I hear is that it makes Intellisense more efficient. My standard response to that is that if you have so many locals/members/properties/controls that you need Intellisense to help you sort them out, then you probably need to refactor your code.
June 1, 2004 11:04 PM
 

Kevin Dente said:

Rory - that last response was to an earlier comment, not yours.

Are you saying that you use K&R style, opening-brace-on-them same line e.g. "if (true) {"? If so, then by god YOU MUST BE DESTROYED. :P

I've never understood K&R style bracing. Have people no appreciation for symmetry, by gum?
June 1, 2004 11:08 PM
 

Rory said:

Kevin -

"YOU MUST BE DESTROYED."

I understand that some people are sensitive about the issue :)

"Have people no appreciation for symmetry, by gum?"

When I was a kid, I didn't have enough Legos to make anything symmetrical. My appreciation for that curly brace style is the direct result of having been a poor child who had to create Lego spaceships with only one wing.

Pity me, Kevin. Don't hate me.

*Pity* me :)
June 1, 2004 11:33 PM
 

Kevin Dente said:

Pity *you*? I pity the fool that has to read your code. :P

June 2, 2004 12:12 AM
 

bliz said:

oIWishThatICouldBeAsLovelyAsATree
June 2, 2004 1:46 AM
 

Andy said:

I don't know what everyone else does but I am a creature of habit. You can look at my code from any project and my naming convention is always the same.

Pascal case for class names, enums, and namespaces IE:

namespace FormControls{
class TextBox : public SimpleControl{
};
}

underscores for instances of classes IE:
TextBox* _TextCustomerName = new TextBox;

local function variables are Camel cased IE:
std::string GetCustomerName(){
std::string customerName(_TextCustomerName->GetString());
return customerName;
}

yada yada yada.

A long time ago I sat down and figured out what was easiest for me to read if I had to come back to my code a long ways down the road and change or extend it. I wrote it all down and now unless the place I'm working demands different I always use that style. I can print out my page of rules and stick it into any of my projects and whoever comes after can instantly read my code. It may not be the style everyone likes but the people who come after me have never had anything but good to say about mantaining it. I think even if you use a style not everyone likes so long as you document it and stay 100% consistant those who come after you won't complain to much if at all.
June 2, 2004 2:29 AM
 

secretGeek said:

Now now Rory. You forgot your pills again and got all *angry*.

"The world would be a much better place if we all conformed to one set of style guidelines"

And had one skin colour, one hair colour... right HITLER???

nah, i still loves ya.

leon

June 2, 2004 2:48 AM
 

Charles Simonyi said:

Intense discussion. One thing that is not made very clear (except in the original paper) is the distinction between "implementation type" like long or object and the "intentional type" which can be for example a "x coordinate relative to my galley area of the window". While knowing the implementation type is not very useful (and is also checked by the compiler), knowing the intentional type is critical to understanding the program. Abbreviation is important so that all the information listed in the example can be included in the name.
Calls for a common convention are meaningless unless one is willing to say what the conventions are. But I would agree that the Hungarian conventions had not been explained well and the bad drove out what could have been good.
June 2, 2004 5:01 AM
 

Kevin Dente said:

Charles - ah, what do you know about it, anyway? Oh, wait... ;)
June 2, 2004 5:49 AM
 

Rory said:

Charles -

While I'm sure there was a lot of good academic effort put into Hungarian notation, the result in the workplace isn't pretty.

It's especially not pretty when it's used in such a way that it simply doesn't make sense (such as the "o" prefix I wrote about - it's just messy and pointless).

When I first encountered Hungarian Notation, I loved it. But that was back when I was doing a lot of VB stuff and was dealing with huge quantities of procedural code that consisted of 6,000 If statements all strung together. When code is really bad, I've found Hungarian notation to be helpful.

However, with Java and C#, I haven't run into as much of the "let's write our entire app in one method" style of coding. Plus, the IDEs are so slick that type can be discovered quite quickly without having to have a confusing non-standard prefix on the variable (another reality of Hungarian notation is that each coder reinvents it to meet his/her own preferences, resulting in mess, mess, mess).

I guess I see it as something that did well for its time, but which is no longer needed. I don't mean any disrespect at all, but I *do* wish it would go away.
June 2, 2004 8:15 AM
 

Tim Scarfe said:

"What I've decided is this: Magazines should no longer take submissions from authors who don't write their code according to the Microsoft style guidelines."

While I agree on principle, I don't like anyone telling me how to code. There are only so many guidelines that fit an art.
June 2, 2004 8:50 AM
 

Rory said:

Tim -

"While I agree on principle, I don't like anyone telling me how to code. There are only so many guidelines that fit an art."

Coding isn't really an art, though - it's a craft.

With art, you don't have to worry about how maintainable or easy to understand the product of your efforts is. Plus, you can often just not think about other people who will have to work with what you've done.

Coding is very different...
June 2, 2004 9:20 AM
 

dak said:

"I went back and forth a lot about '_' and eventually decided to go without. But I *hate* 'm_' - just can't stand it."

I don't usually employ a prefix to indicate instance variables any more, since "this." isn't too much of an annoyance to type (and lets me use Intellisense, so I may actually save key strokes). But when I did I liked "my" (or, if I was feeling weird, "its"). As in, myName, myAddress, or myLocation.
June 2, 2004 9:43 AM
 

Josh Pollard said:

"But when I did I liked "my" (or, if I was feeling weird, "its"). As in, myName, myAddress, or myLocation."

I would always yell at myself if I started to name a variable "my" something. The reason I hate doing that is because that is how most of the example code in the msdn help files are written. I didn't want anyone to look at my code and think "wow, all he did was copy and paste a whole bunch of code from msdn"

As to the Hungarian notation, I still use it in .NET. I realize that I can move the mouse over the variable to find out what it is, but what if both of my hands are on the keyboard? Or, another likely scenario, I'm looking over some code with my left hand on the keyboard and my right hand supplying coffee to my mouth! :-)
June 2, 2004 11:51 AM
 

Sam said:

My only complaint is that you spent most of your blog post 'poo-pooing' Hungarian notation, and not much time talking about alternatives.

Personally I like Hungarian notation, and I don't see anything wrong with it. It would be nice if everyone was more consistant, but if I declare an integer, its always going to be intMyVar.
June 2, 2004 12:22 PM
 

Mike Dimmick said:

In an environment that has sensible, safe type conversion rules, the 'implementation type' prefix shouldn't be necessary. The compiler catches that kind of error. Unfortunately, classic C and VB6 can hardly be called sensible or safe. C++ has minor improvements - I'll use the type warts when using the built-in types, but generally not for class types (which are very strongly checked, barring implicit constructors and conversion operators).

VB.NET is better once you've turned Option Strict on. My personal view is that everyone should enable Option Strict in VB.NET, but I've been overruled at work due to the amount of extra typing you have to do. I'm not really a fan of dynamic-typed languages like Python, Perl or VBScript - I guess I don't really do quick-and-dirty because it always turns into quick-and-unmaintainable.

Most of our languages don't have the type range restriction features of Ada, nor its ability to produce new names for existing types, where objects declared using those new type names are not implicitly convertible to the original type. Without this, it can be useful to indicate the 'intentional type', as Charles puts it.
June 2, 2004 12:46 PM
 

Rumen Stankov said:

My rule is that underscores in general should not be used in managed C# code. Furthermore, public API members starting with "_" are not CLS compliant - so you cannot compile your assembly when the CLSCompliantAttribute is set to true.

CLS Compliance is often a requirement in enterprise projects.
June 2, 2004 12:58 PM
 

Dave Donaldson said:

OK, yet another opinion on this topic:

I for one am for Hungarian notation, at least its current form (by that I mean I think the original Hungarian notation used the prefix "sz" for strings, but now a lot of people use "str").

Rory, you're basically saying that the IDE is smart enough for us not to use it, so Hungarian notation is no longer required. True, but what about code reviews? There is no IDE there. It's just code printed on paper to have other eyeballs look at it. So if the developer has a variable named "amount", what is its type? Integer? Single? Double? Long? But if the variable is named "intAmount" you know right away. You don't have to ask or scroll up in the code to find out.

And as for the "o" prefix, yes everything is an object, but what *type* of object is it? Is it a DataGrid, a DataSet, a Command object? If you name a variable "dsPolicies" you'll know it's of type DataSet immediately.

Of course, according to guidelines, Hungarian should be limited to private members and nothing on the public interface.
June 2, 2004 4:09 PM
 

Petes said:

mmmmm, how hard would it be to write a program to parse and alter the coding convention of your code or at least convert the code to comply to a certain coding convention. This would allow the user to view the code using whatever coding convention they desire.
June 2, 2004 4:35 PM
 

Mark Freedman said:

Sam, the alternative is to NOT use Hungarian notation. So, therefore, the alternative is the *absence* of hungarian notation.

So with zero words, Rory offered his alternative. ;)
June 2, 2004 4:53 PM
 

Rory said:

Dave -

"I for one am for Hungarian notation, at least its current form (by that I mean I think the original Hungarian notation used the prefix 'sz' for strings, but now a lot of people use 'str')."

But we get into problems just in this small paragraph.

You like "sz," other people like "str," and I've seen quite a bit of plain old "s."

Blah :)

"but what about code reviews? There is no IDE there. It's just code printed on paper to have other eyeballs look at it."

I like to think that the code I'm writing is clear enough that even on paper nothing's a mystery. I'm *really* anal about cleanliness of code.

If it's tough to figure out what a particular object is without shuffling papers and highlighting segments, playing code detective, then I haven't done my job :|

"And as for the 'o' prefix, yes everything is an object, but what *type* of object is it? Is it a DataGrid, a DataSet, a Command object? If you name a variable 'dsPolicies' you'll know it's of type DataSet immediately"

Ideally, it should be clear what the object is without having to use Hungarian.

I think that part of the hurdle is for people who are very used to Hungarian. What's tough to realize from the outset is that it's not actually harder, and your code will be much cleaner once it's gone.

I'm a stickler about this, though. Java taught me to use camel casing, and I think Java was right...
June 2, 2004 5:45 PM
 

Rory said:

Sam -

"Personally I like Hungarian notation, and I don't see anything wrong with it. It would be nice if everyone was more consistant, but if I declare an integer, its always going to be intMyVar."

See, though, that "intMy" stuff just gets to be sort of pointless. What's the "My" for anyway? That's something I've always wondered.

I'm usually happy with something like:

int age = 0;

I can see that it's an int, and I'm not going to add so much code to the method that this is obscured. I have a pretty good feeling that it's one of "my" variables, and its name tells me exactly what it's holding. The name of the method and the overall purpose of the app will give me further context if I need it, but I probably *won't* need it.
June 2, 2004 5:51 PM
 

Jason Olson said:

I'm totally with Rory on this one. I may be lazy in real life but when it comes to coding, I am extremely anal.

One concept that has not been brought that I think is *vital* for *any* modern programmer to read about is refactoring. Like Rory said, if there is a section of code that leaves other developers with a doubt of what the code does, we haven't done our job as developers. For goodness sakes, use "extract method" and move that section of code out into it's own method whose name describes what the section of code does. While I know this isn't always easy, I contend that it *is* always possible. It may take more time up-front, but it will save many man-hours in the long run, TRUST ME!

With some of the refactoring tools in Visual Studio 2005, this issue becomes even more important. The IDE is even more functionality-rich and any coder too lazy to use those tools should be shot on the spot. Code is not something you just slap together. It is something that needs to be planned out and done right (whether the planning is all up-front, or whether it is done XP-Style with refactoring and design patterns, I don't care, as long as it *is* done).

I know while Refactoring isn't directly applicable to the death of Hungarian notation, I think it kills off certain arguments people have for using Hungarian notation. For example, the code review. if the code is properly written, there should not be a single section of code that doesn't "make sense". With straight-forward refactorings like "extract method", someone should be able to easily understand what the code is doing at any point in time.

* <DISCLAIMER> *
I understand that the beauty of refactoring and detailed code may not be possible on platforms that need the most performance squeezed out (like mobile platforms). In those situations, I can definitely forgive the sins because they aren't *really* sins.
* </DISCLAIMER> *
June 2, 2004 7:11 PM
 

Dave Donaldson said:

I understand everyone's point about not using Hungarian notation, believe me I do. But I don't think it gets in the way of writing clean code at all. I am a freak about clean code. I cannot stand messy code. I am also completely anal about it.

I don't think the refactoring issue applies to this particular argument. I refactor ALL THE TIME and still use the notation.

And if my code is clean and refactored well, does using Hungarian notation hinder your ability to read it or maintain it? I doubt it.

Writing code is as much a matter of style than anything, and some people prefer to use it and others don't.
June 2, 2004 8:21 PM
 

Dave Donaldson said:

BTW, don't you just love religious debates like this? Gets the juices flowing :-)
June 2, 2004 9:39 PM
 

Jason Olson said:

Dave -

I was just pointing out how Refactoring is a rebuttal against some of the arguments people use as to *why* they use Hungarian notation. I understand that refactoring doesn't apply to the direct argument of whether to use Hungarian notation or not. I was just trying to stir up the pot a little ;).
June 2, 2004 10:22 PM
 

bliz said:

How do you name your UI widgets? Do you add txtFirstName or btnSubmit (which is similar to Hungarian)? Do you spell it out, such as FirstNameTextbox or SubmitButton? Or do you leave off indication that it's a widget, and just go with FirstName, Submit? Just curious.
June 2, 2004 10:39 PM
 

Jason Olson said:

Personally, I go back and forth with this one. The butchered style Hungarian that is used like txtFirstName and btnSubmit, I don't have that much of a problem with. Currently, I would name the controls firstName and submit. If you catch me tomorrow though, I might name them txtFirstName and btnSubmit. I still haven't arrived at a conclusion for UI widgets.

The one thing I dislike about txtFirstName is that know your form may have some members that use a hacked hungarian notation and others that don't (the private/protected/public variables used in the rest of our code behind). At least if I name it firstName instead of txtFirstName, I have the same naming convention whether the member variable be a user interface element or not.

That's just me though...
June 2, 2004 11:37 PM
 

Jason Olson said:

oops, "now your form" not "know your form". Proceed.....
June 2, 2004 11:38 PM
 

Jeremy Brayton said:

True camel case per the guidelines suggest writing out the entire type.

So instead of say cmb, it's comboBoxFirstName or something like that. It makes more sense to write it all out because there is no second guesses. If you don't know what a comboBox is, you shouldn't be coding.

There was some hungarian notations that almost overlapped. I forget which ones they were, but because they were so close I got them mixed up. Plus when you're only given 3 characters, versus say 255, you're really limiting your capabilities. Think file extensions and you'll understand what I mean, or 8.3 DOS filenames if you need another life-line.

I personally hate redundancy in code. Rory hit one in the head. oWordObject. Convert that to camel case per the guidelines and it'd be called objectWordObject. Redundant? Severely. Why on earth would you want to do that? Putting the first object or o SHOULD omit the second object in the definition, but some people leave it.

Plus lets be honest here. How many image applications can you have that do basically the same thing. I don't get why this profession insists on reinventing the wheel over and over again. I mean I know there's room for improvement in almost all code, but to completely redo it instead of improve on existing code seems foolish. I guess people like getting paid for work they really didn't have to do, but because they are so anal they insist on recoding something that's been done 50 million times already. That's why I love .NET. Microsoft realizes that because so much has been done and redone, they're putting tools in our hands that keep us from redoing what's been proven and works. If it works 100% of the time and there's no room for improvement, why do it over? I just don't get it. I probably never will. I'm anal about efficiency in all forms and programming as a profession has severe lack of efficiency in just about every area. I know you have to make money, but have you really earned it?
June 3, 2004 12:39 AM
 

Timothy Lee Russell said:

If you look at the .NET MCSD certification books from Microsoft, they use short (i.e. txtVariable) hungarian notation for the code examples so it is understandable that programmers would mistakenly follow that convention.

However, I prefer a reverse style because of intellisense. So, I might name a TextBox, UserBiographyTextBox. When I am writing code, I am thinking about the purpose of the object (UserBiography), not its Type (TextBox).

Basically, I find that the alphabetic sorting of intellisense in the VS.NET IDE affects my coding style.
June 3, 2004 2:18 AM
 

Charles Simonyi said:

User Petes has the right idea in that names (or for that matter the syntax or other notation) should be dynamically changeable. I've been advocating the separation of identity (which is unambiguous) from the names which would be used only for interfacing with the programmer and which can be ambiguous and there could be multiple names, even names that are preferred only by particular members of the team and which no one else would need to look at.

We have been writing a lot of C# code this year and we returned to strict Hungarian - using the intentional type. Here an instance of class Xrf would be declared Xrf xrf; certainly not oXrf, or objectExternalReference.
An interesting point about terse names like xrf which has not been mentioned is this: it does not carry emotional bagagge to the reader, the way External Reference would. The latter tends to mislead people. Plus it is pure hubris on the programmer's part. Why does the programmer think that there will be only one kind of external reference (or name table, or location record, etc.) in the program? By the time the program is finished there will be many and people will use creative misspellings and similar abominations to distinguish them. Also I noticed how names tend to shorten as the deadlines near. To me xrf is more honest: it is just what it is, where it is. The reader just has to read the comments, understand the invariants and understand the logic.
June 3, 2004 4:38 AM
 

Chance Gillespie said:

I can’t stand Hungarian Notation myself. Makes me want to shave my cat and drink lighter fluid every time I encounter it. That said, I do have a little bit of a double standard on the matter. I DO prefix field names for Windows Forms controls (mnu for menu, btn for button, etc.).

As for the leading ‘_’ for class fields, I think this is a good practice. Prefixing or casing based on scope is much more useful these days than Hungarian Notation as it’s information that’s not as easily gleaned from the IDE as object type is. I have always struggled with that one and was never able to settle on a style that I was totally happy with until I started coding in C# (not sure why it didn’t hit me till then). I’m sure you all are dying to know so I’ll share my style with you :)

Properties: PascalCased
class fields: _camelCasedWithLeadingUnderscore
method arguments: camelCased
local method variables: lower_case_with_enderscores

The only possible ambiguity there is for method arguments and local method variables. If the name only contains one lower cased word then it could be either a method argument or a local variable. Since these are both scoped to the method they are in it’s not a major issue.

Change is good but since I’ve been looking for a style that really works for me for so long I’ll probably be using this one for quite some time. Really happy with it.
June 3, 2004 3:28 PM
 

Chance Gillespie said:

I should quantify that a bit further. VS will indicate scope when hovering over the identifier but I tend to use intellisense for type determination more than I use the mouse hover. Following the identifier with a ‘.’ causes intellisense to give me the larger set of information that I’m after. Intellisense doesn’t give me that sort of information about scope.
June 3, 2004 3:55 PM
 

Anonymous said:

June 4, 2004 4:17 AM
 

Tim Scarfe said:

Rory-

""While I agree on principle, I don't like anyone telling me how to code. There are only so many guidelines that fit an art.""

"Coding isn't really an art, though - it's a craft. "

"With art, you don't have to worry about how maintainable or easy to understand the product of your efforts is. Plus, you can often just not think about other people who will have to work with what you've done. "

"Coding is very different... "

Well I don't agree but anyway if I were you I would concern yourself far more with people’s ability to administer the Analysis and Design parts of the development cycle (translate: OOD, Data Modelling, Mythologies, Practices).

I'd rather read well designed/architected/thought-out Hungarian code than .NET guideline style code. Where is the craft in that pal? It isn't there.


June 4, 2004 9:51 AM
 

Anonymous said:

I remain unconvinced (even though I missed the majority of this conversation while offline).

Consider this:

NumberOfPosts - Proper notation (I think, anyway - there's some rules for Of) but is it an int? A short? Long? Constant? Static? Can't tell can ya. That means you have to go look it up OR wait for the ToolTip from the compiler. I still like the Hungarian idea: you know exactly what type the variable is without having to dig into headers and/or declarations.

Of course, given my new employers views of such things, I will eventually be broken and forced to conform, but for right now I remain defiant!
June 9, 2004 12:28 PM
 

Jeffrey Palermo said:

I agree that we should conform to the MS recommended guilelines for developing our .Net libraries, but what about html? What about the javascript in our ASP.NET? What about web forms controls? In Javascript, all the .Net strongly-typed arguments go out the window. Also, our html names for web controls are used in our code-behind (rdoYes, txtName).
June 18, 2004 1:42 PM
 

Pxtl said:

Hungarian notation is stupid for type info. Most projects should have so many internal classes that the type information is pointless anyways. What if you never use arrays, but always vectors? There is no prefix for vector, whereas there is one for array.

I use a modified Hungarian wherein you only use it for scoping and membership information - not type information. Scoping is unlikely to change and you can't make up custom scopes the way you can custom types. The only "type" one that seems useful to me is pointer.

If you have a global constant, that deserves a prefix (gk). If you want to differentiate the members from the locals, the m prefix makes sense (I ditch the underscore).

Plus, it keeps the notation short enough that I can simply as part of my standard heading comment block, so any coder who has the sense to read it will know my conventions, rather than the _true_ hungarian notation which requires a lengthy document.

Oh, and same goes to you people who love to call it "WORD". Its an unsigned int - its already got a name, thanks. No pointless typedefs plz.
July 21, 2004 3:46 PM
 

Randy Jackson said:

Thanks Rory I've been looking for that link for a month.
August 25, 2004 11:13 PM
 

OOOYY said:

http://dmm001.googlepages.com/2772.htm ????
http://dmm001.googlepages.com/2774.htm ???
http://dmm001.googlepages.com/2775.htm ????
http://dmm001.googlepages.com/2776.htm ??????
http://dmm001.googlepages.com/2777.htm ??????
http://dmm001.googlepages.com/2778.htm ??????
http://dmm001.googlepages.com/2779.htm ????
http://dmm001.googlepages.com/2780.htm ????
http://dmm001.googlepages.com/2781.htm ????
http://dmm001.googlepages.com/2782.htm ?????
http://dmm001.googlepages.com/2783.htm ????
http://dmm001.googlepages.com/2784.htm ????
http://dmm001.googlepages.com/2785.htm ????
http://dmm001.googlepages.com/2786.htm ????
http://dmm001.googlepages.com/2787.htm ????
http://dmm001.googlepages.com/2788.htm ????
http://dmm001.googlepages.com/2789.htm ??????
http://dmm001.googlepages.com/2790.htm ??????
http://dmm001.googlepages.com/2791.htm ??????
http://dmm001.googlepages.com/2792.htm ??????
http://dmm001.googlepages.com/2793.htm ??????
http://dmm001.googlepages.com/2794.htm ??????
http://dmm001.googlepages.com/2795.htm ??????
http://dmm001.googlepages.com/2796.htm ??????
http://dmm001.googlepages.com/2797.htm ????
http://dmm001.googlepages.com/2798.htm ???
http://dmm001.googlepages.com/2799.htm ??av??
http://dmm001.googlepages.com/2800.htm ????
http://dmm001.googlepages.com/2801.htm ??????
http://dmm001.googlepages.com/2802.htm ??????
http://dmm001.googlepages.com/2803.htm ????
http://dmm001.googlepages.com/2804.htm ????
http://dmm001.googlepages.com/2805.htm ????
http://dmm001.googlepages.com/2806.htm ????
http://dmm001.googlepages.com/2807.htm ????
http://dmm001.googlepages.com/2808.htm ????
http://dmm001.googlepages.com/2809.htm ????
http://dmm001.googlepages.com/2810.htm ??????
http://dmm001.googlepages.com/2811.htm ??????
http://dmm001.googlepages.com/2812.htm ??????
http://dmm001.googlepages.com/2813.htm ??????
http://dmm001.googlepages.com/2814.htm ?????
http://dmm001.googlepages.com/2815.htm ???????
http://dmm001.googlepages.com/2817.htm ??? ??
http://dmm001.googlepages.com/2818.htm ??a?
http://dmm001.googlepages.com/2819.htm ????
http://dmm001.googlepages.com/2820.htm ?????
http://dmm001.googlepages.com/2821.htm ??????
http://dmm001.googlepages.com/2822.htm ??????
http://dmm001.googlepages.com/2824.htm ??????
http://dmm001.googlepages.com/2825.htm ??????
http://dmm001.googlepages.com/2828.htm ??
http://dmm001.googlepages.com/2732.htm ??????
http://xdmmll.googlepages.com/2407.htm ????
http://xdmmll.googlepages.com/2408.htm ????
http://xdmmll.googlepages.com/2409.htm ????
http://xdmmll.googlepages.com/2379.htm ????
http://xdmmll.googlepages.com/2380.htm ????
http://xdmmll.googlepages.com/2381.htm ????
http://xdmmll.googlepages.com/2382.htm ????
http://xdmmll.googlepages.com/2383.htm ????
http://xdmmll.googlepages.com/2384.htm ????
http://xdmmll.googlepages.com/2385.htm ????
http://xdmmll.googlepages.com/2386.htm ??????
http://xdmmll.googlepages.com/2387.htm ??????
http://xdmmll.googlepages.com/2388.htm ??????
http://xdmmll.googlepages.com/2389.htm ??????
http://xdmmll.googlepages.com/2390.htm ??????
http://xdmmll.googlepages.com/2391.htm ??????
http://xdmmll.googlepages.com/2392.htm ??????
http://xdmmll.googlepages.com/2410.htm ????
http://xdmmll.googlepages.com/2411.htm ???
http://xdmmll.googlepages.com/2412.htm ???
http://xdmmll.googlepages.com/2413.htm ???
http://xdmmll.googlepages.com/2728.htm ??????
http://xdmmll.googlepages.com/2907.htm ????
http://xdmmll.googlepages.com/2908.htm ????
http://xdmmll.googlepages.com/2909.htm ??????
http://xdmmll.googlepages.com/2372.htm ?????
http://xdmmll.googlepages.com/2373.htm ?????
http://xdmmll.googlepages.com/2374.htm ?????
http://xdmmll.googlepages.com/2375.htm ?????
http://xdmmll.googlepages.com/2376.htm ?????
http://xdmmll.googlepages.com/2377.htm ?????
http://xdmmll.googlepages.com/2378.htm ?????
http://xdmmll.googlepages.com/2393.htm ??????
http://xdmmll.googlepages.com/2394.htm ??????
http://xdmmll.googlepages.com/2395.htm ??????
http://xdmmll.googlepages.com/2396.htm ??????
http://xdmmll.googlepages.com/2397.htm ??????
http://xdmmll.googlepages.com/2398.htm ??????
http://xdmmll.googlepages.com/2399.htm ??????
http://xdmmll.googlepages.com/2400.htm ??????
http://xdmmll.googlepages.com/2401.htm ??????
http://xdmmll.googlepages.com/2402.htm ??????
http://xdmmll.googlepages.com/2403.htm ??????
http://xdmmll.googlepages.com/2404.htm ??????
http://xdmmll.googlepages.com/2405.htm ??????
http://xdmmll.googlepages.com/2406.htm ??????
http://xdmmll.googlepages.com/2431.htm ???
http://xdmmll.googlepages.com/2432.htm ?????
http://xdmmll.googlepages.com/2433.htm ?????
http://xdmmll.googlepages.com/2434.htm ??????
http://xdmmll.googlepages.com/2414.htm ??
http://xdmmll.googlepages.com/2415.htm ????
http://xdmmll.googlepages.com/2416.htm ????
http://xdmmll.googlepages.com/2417.htm ??
http://xdmmll.googlepages.com/2418.htm ??
http://xdmmll.googlepages.com/2419.htm ??????
http://xdmmll.googlepages.com/2420.htm ????
http://xdmmll.googlepages.com/2421.htm 18??
http://xdmmll.googlepages.com/2422.htm ??18
http://xdmmll.googlepages.com/2423.htm ????
http://xdmmll.googlepages.com/2424.htm ????
http://xdmmll.googlepages.com/2425.htm ????
http://xdmmll.googlepages.com/2426.htm ????
http://xdmmll.googlepages.com/2427.htm ???????
http://xdmmll.googlepages.com/2428.htm ?????????
http://xdmmll.googlepages.com/2429.htm ?????????
http://xdmmll.googlepages.com/2430.htm ??????
http://xdmmll.googlepages.com/2435.htm ?????????
http://xdmmll.googlepages.com/2436.htm ???????
http://xdmmll.googlepages.com/2437.htm ???????
http://xdmmll.googlepages.com/2438.htm ???????
http://xdmmll.googlepages.com/2439.htm ????????
http://xdmmll.googlepages.com/2440.htm ??????????
http://xdmmll.googlepages.com/2441.htm ????????
http://xdmmll.googlepages.com/2442.htm ???????
http://xdmmll.googlepages.com/2443.htm ??????????
http://xdmmll.googlepages.com/2444.htm ??????
http://xdmmll.googlepages.com/2445.htm ??????????
http://xdmmll.googlepages.com/2446.htm ???????
http://xdmmll.googlepages.com/2447.htm ??????
http://xdmmll.googlepages.com/2448.htm ?????
http://xdmmll.googlepages.com/2449.htm ??????
http://xdmmll.googlepages.com/2450.htm ????
http://xdmmll.googlepages.com/2451.htm ???
http://xdmmll.googlepages.com/2452.htm ??????
http://xdmmll.googlepages.com/2453.htm ????
http://xdmmll.googlepages.com/2454.htm ????
http://xdmmll.googlepages.com/2455.htm ????
http://xdmmll.googlepages.com/2456.htm ????
http://xdmmll.googlepages.com/2457.htm ????
http://xdmmll.googlepages.com/2458.htm ????
http://xdmmll.googlepages.com/2459.htm ????
http://xdmmll.googlepages.com/2460.htm ????
http://xdmmll.googlepages.com/2461.htm ????
http://xdmmll.googlepages.com/2462.htm ????
http://xdmmll.googlepages.com/2463.htm ????
http://xdmmll.googlepages.com/2464.htm ?????
http://xdmmll.googlepages.com/2465.htm ?????
http://xdmmll.googlepages.com/2466.htm ?????
August 14, 2006 2:38 AM
 

TrackBack said:

Kill those warts!
June 3, 2004 4:04 PM
 

TrackBack said:

Whidbey Unit Testing Generated Code - yikes
June 4, 2004 12:38 AM
 

TrackBack said:

Office Information Bridge Framework
June 4, 2004 10:56 AM
 

TrackBack said:

Nameing Guidelines from MS
June 7, 2004 2:44 AM
 

TrackBack said:

Naming Guidelines from MS
June 7, 2004 3:54 AM
 

TrackBack said:

Hugarian notation - it's my turn now :)
June 22, 2004 6:00 PM
 

TrackBack said:

Hugarian notation - it's my turn now :)
June 24, 2004 5:06 AM
 

TrackBack said:

程序函数和变量的命名
April 15, 2006 1:56 AM
 

Austen said:

http://bab098047cd57284c694cfb28217220d-t.dh4t5gef.info <a href="http://bab098047cd57284c694cfb28217220d-h.dh4t5gef.info">bab098047cd57284c694cfb28217220d</a> [url]http://bab098047cd57284c694cfb28217220d-b1.dh4t5gef.info[/url] [url=http://bab098047cd57284c694cfb28217220d-b2.dh4t5gef.info]bab098047cd57284c694cfb28217220d[/url] Broken Heart [U]http://bab098047cd57284c694cfb28217220d-b3.dh4t5gef.info[/u]
January 17, 2007 8:31 AM
New Comments to this post are disabled

About Rory

I *own* this site, you loser.

This Blog

Post Calendar

<June 2004>
SuMoTuWeThFrSa
303112345
6789101112
13141516171819
20212223242526
27282930123
45678910

Post Categories

Feeds
Copyright Rory, 2007. All rights reserved.