What's the story with Hungarian Notation these days?

[Kevin Marois]

I'v been coding for 25 years. Camel case is a throwback from the days when all variables has to start with a lowercase letter.

If it's not broken, fix it until it is

[Vark111]

In the same vein of a previous reply I left... I use underscores before my private members because that's the default setting for the style checker built into Resharper, and I'm loath to change default settings. Makes setting up new systems and syncing with coworkers easier.

[OriginalGriff]

I (mostly) use Camel case exclusively in C# - because it's the standard. I can't seem to break myself of butOK and butCancel, dgvListNotes and so from though for controls, which harks back to my Hungarian C++ days. I do use underscores - for Property bases only, to differentiate them from the Property and to make it harder for me to accidentally use the wrong one - set the Property instead of the base in the Property setter, and so forth... :-O

If you get an email telling you that you can catch Swine Flu from tinned pork then just delete it. It's Spam.

[Ravi Bhavnani]

True. :( /ravi

My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com

[bwhittington]

I only use Hungarian Notation when naming controls on a win and web forms. I it like this because of intellisense will then show all like control together.

Brett A. Whittington Application Developer

[_beauw_]

I don't think that the fundamental aspects of the C/C++ type system that led to Hungarian notation have really changed. At least, this is true in the realm of unmanaged C++. Hungarian notation didn't simply go out of style... it was (and is) a product of the Windows API's design.

[Ennis Ray Lynch Jr]

Ah, but that is a prefix, and no prefixes are allowed :) Amazing how you can hear that argument from people that can justify using the prefix _ but no other prefix, not saying that you do, I get it. But come on, if you are going to prefix, use m. It has a meaning. I really think MS choose _ because they intentionally didn't want to use m. Personally, I use m. I just hate the "justification" for _ so I definitely understand and desire the need to know whether it is a member or a local.

Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. I also do Android Programming as I find it a refreshing break from the MS. "And they, since they Were not the one dead, turned to their affairs" -- Robert Frost

[Ennis Ray Lynch Jr]

Doing something because it is easier is not really a justification. 99% of the time it is easier to not explain to people why using the as operator (not alias) is a bad idea; yet I dissallow it on my teams and fight the battle every time. I refuse to code at the lowest common denominator. Of course, I also allow everyone on my teams to code using their own style. 1) It fosters productivity, 2) If you can't read it you shouldn't be in charge anyway, 3) If it is really bad it makes it easy to fix through shared learning, 4) I can spot everyone's code from a mile away so I know what kind of errors to look for. People make the same mistakes over and over. But I can see the good in a universal standard, no thinking, no achievement, no responsibility, and no accountability. I better stop now before this turns into a complete rant against the "institution"

Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. I also do Android Programming as I find it a refreshing break from the MS. "And they, since they Were not the one dead, turned to their affairs" -- Robert Frost

[bwhittington]

Could you explain to me or give me a reference to why "as" operator is bad? I use this all the time so I can check for nulls instead of throwing an exception. I did a search on as operator and all I found was a bunch of references on how to use it but not why it shouldn't be used. Thanks!

Brett A. Whittington Application Developer

[Ennis Ray Lynch Jr]

As is used a blind assumption, for example, lets define a

public class Customer{
public string Id{
get;
set;
}
}

Now, lets use what seems like a perfectly valid blind assumption that the data in the table is always a string, because the db definition was at the time.

while(reader.Reader(){
Customer customer = new Customer();
customer.Id = reader["id"] as string;
}

Now lets presume, that someone realized that customer Id was incorrect in the db and fixes it to be the correct integer version. You will get an error in your code, the question is where and when, and at what crucial juncture? My example is contrived for simplicity but I got this exact error in a code-review after it crashed. I had told the specific developer to not use AS but, well, sure enough, when the DB schema changed the application crashed and no one could figure out why. (Fortunately, this was in development not production but given how some places work ...) Now lets look at some additional code

while(reader.Reader(){
Customer customer = new Customer();
customer.Id = (string)reader["id"];
}

This will crash immediately, and on target. One, we know that Customer Id shouldn't be null, and two, we know that null in the db is DBNull.Value so not directly assignable. While more verbose, in the case of fields that allow null, I still prefer:

while(reader.Reader(){
Customer customer = new Customer();
customer.Id = reader["id"] == DBNull.Value ? null | (string)reader["id"];
}

Again, it is about identifying errors reliably as soon as possible without too much code. After all, try and justify this one

while(reader.Reader(){
Customer customer = new Customer();
customer.Id = reader["id"] as string;
if(customer.Id == null){
throw new NullFieldException("wtf this should never happen");
}
}

So what it boils down to is the "as" operator introduces a non-trivial bug in potentially crucial areas. Type checking is very important and the assumption of conversion is a flaw, in my opinion. That is why strong typing is an asset. "as" is a way around strong typing, IMHO. YMMV. Note: customerId is defined as not null in the db.

Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on

[bwhittington]

Thank you for the detailed explanation. I typically use the 'as' keyword when I am looking for controls using .FindControl when I am dynamically binding data which I think would be a good case to use the 'as' operator. But because of my familiarity with it, I am also using it in situations you described where it is dumb to check for null and then just throw another exception. I've got a bit to think about. Thanks again.

Brett A. Whittington Application Developer

[Vark111]

Ennis Ray Lynch, Jr. wrote:

no thinking, no achievement, no responsibility, and no accountability

You forgot making source control diffs unusable and merges a royal pain in the rear.

[Clifford Nelson]

Personally I like the underscore for private variables. Makes them easy to find, and you know they are private class level. ReSharper enforces it. However when I was at Intel, I lost the battle to prefix with an underscore. Of course I was just a contractor, and there was an ex-contractor/new employee, who seemed like to take any position that was the opposite of mine, just to be an a$$. I think he did not appreciate that I did not think he was god of programming.

[Ravi Bhavnani]

IIRC, the Java convention is also to use m_ m. /ravi

My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com

[RugbyLeague]

I use Bulgarian notation

[BillWoodruff]

Ennis Ray Lynch, Jr. wrote:

But I can see the good in a universal standard, no thinking, no achievement, no responsibility, and no accountability.

Hi, Ennis, I enjoyed reading, and pondering over, your responses on this thread; particularly your detailed explication of your views on the "dangers of type conversion using 'as'." The example given, of a potential mis-match between the type of a database field, and its use, by mistake, in code as another type, I found a bit hard to follow, since both "casting," and use of "as," to convert int to string, and the reverse, will all generate compile time errors:

private string aStr = "1234";
private int someInt = 1234;

int y1 = (int) aStr;
// Cannot convert type 'string' to 'int'

string z1 = (string) someInt;
// Cannot convert type 'int' to 'string'

int y2 = aStr as int;
// The as operator must be used with a reference type or nullable type ('int' is a non-nullable value type)

string z2 = someInt as string;
// Cannot convert type 'int' to 'string' via a reference conversion, boxing conversion, unboxing conversion,
// wrapping conversion, or null type conversion

Your final, broad statement quoted above re "universal standard" equating with ... well, the broad negations you imply ... just does not communicate to me clearly what I think you mean as a broad philosophical/pragmatic principle: care to explicate that a bit further ? I think the development of "intellisense" to the level you now find it at in Visual Studio (and the "enhanced" extension of "intellisense" that can be added-on via tools like ReSharper), makes use of meaning-bearing prefixes often very useful. Sometimes your IDE can influence your use of prefixes (?): imagine you have a VS Studio Project, WinForms, for example, where you have loads of controls; I find prefixing each control with a type prefix like "cb_" for a CheckBox, with the prefix followed by a mnemonic name that indicates function: means: when I go open the drop-down in the Properties Window, all CheckBoxes will appear alphabetic order, which I find useful. Note: it's always seemed curious to me that the native Visual Studio facilities did not include a hierarchic (tree-view) control property-view inspector, that would let you drill-down through nested containers to "filter" the Controls presented by their Containers. I am surprised that the current ReSharper does not offer this enhanced view; perhaps other VS extenders

[Brady Kelly]

I use the underscore to differentiate private members from method parameters, which are both 'supposed to be' camelCase.

[jschell]

Ennis Ray Lynch, Jr. wrote:

I really think MS choose _ because they intentionally didn't want to use m.

Hungarian notation although it existed before Microsoft was basically popularized by that company specifically in relation to C but it was used in C++ as well. And since Microsoft has long term employees, and long time employees tend to get promoted, one might presume that one or more employees preferred it that way. One might suppose that the ANSI C standard had some influence on the choice of underscore since a prefix of two underscores is specifically reserved for certain usages in C. And so certain developers might have thought that using one underscore for Microsoft specific code was appropriate since it wasn't ANSI C but wasn't user code either. And that usage was propagated.

[jschell]

Clifford Nelson wrote:

Personally I like the underscore for private variables. Makes them easy to find, and you know they are private class level.

If you have a significant problem finding your private variables then it would suggest to me that perhaps there is a problem with your classes. Same thing is true if you cannot identify a variable within a class without it. The cases range between the following two extremes but still are relevant. 1. You have never seen the class before. In this case the most significant problem is identifying what the class does and what the implementation is doing. 2. You are very familiar with the class. So you should know what the variables are. Of course if you have classes with hundreds of methods or methods with thousands of lines then identifying private variables is a problem. But what is more of a problem is that the classes and/or methods are too big.

[jschell]

Kevin Marois wrote:

Camel case is a throwback from the days when all variables has to start with a lowercase letter.

I doubt that is an accurate theory for the origin. http://en.wikipedia.org/wiki/CamelCase#Background:_multi-word_identifiers[^]