What's the story with Hungarian Notation these days?
-
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.
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
-
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
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
-
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
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
-
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
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
-
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
-
IMHO, people that use _ in front of members are not using camelCase or Pascal case and are just as guilty as prefixing variables as the hungarian crowd. Oh, yeah, more VB.NET hate
public class Foo{
private int bar;
public int Bar{
get{
return bar;
}
}}
is legal in C#, neener. If you use a case sensitive language, you don't need an underscore.
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
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.
-
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
IIRC, the Java convention is also to use
m_ m. /raviMy new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
Just about every bit of C# code I've seen is uses mostly camel-case names. Just about every bit of C++ code I've seen is written using Hungarian Notation. Why is it still like that?
"I do not have to forgive my enemies, I have had them all shot." — Ramón Maria Narváez (1800-68). "I don't need to shoot my enemies, I don't have any." - Me (2012).
I use Bulgarian notation
-
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
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 conversionYour 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
-
I accept your gripe. :) Two thing about that come to mind: 1. Where's the setter property? 2. I'd opt for an automatic property where possible. I don't like the underscore prefix but I find myself using them because it's almost a requirement and in some places I've been at it's a coding "standard".
"I do not have to forgive my enemies, I have had them all shot." — Ramón Maria Narváez (1800-68). "I don't need to shoot my enemies, I don't have any." - Me (2012).
I use the underscore to differentiate private members from method parameters, which are both 'supposed to be' camelCase.
-
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. 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.
-
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.
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.
-
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
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[^]
-
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.
_beauw_ wrote:
I don't think that the fundamental aspects of the C/C++ type system that led to Hungarian notation have really changed.
I suspect that is wrong. C used untyped parameter passing. Thus even if the method was expecting a int and only a int you could pass a pointer to it. Hungarian lessened the chance of that happening. Additionally there were no IDEs nor online documentation. If you wanted to know what a method definition was you had the following choices 1. Look at the written documentation 2. Find the code in the code base. This was only possible if one had the source. And wasn't necessarily fast even then. 3. Find an example that already used it. With hungarian the last case would provide all of the information about the method. Without it one then would need to look up each of the relevant variables.
-
_beauw_ wrote:
I don't think that the fundamental aspects of the C/C++ type system that led to Hungarian notation have really changed.
I suspect that is wrong. C used untyped parameter passing. Thus even if the method was expecting a int and only a int you could pass a pointer to it. Hungarian lessened the chance of that happening. Additionally there were no IDEs nor online documentation. If you wanted to know what a method definition was you had the following choices 1. Look at the written documentation 2. Find the code in the code base. This was only possible if one had the source. And wasn't necessarily fast even then. 3. Find an example that already used it. With hungarian the last case would provide all of the information about the method. Without it one then would need to look up each of the relevant variables.
Yeah, that's what I meant. So many things that are really different seem the same to the compiler when calling the Windows APIs. This has never really been cleaned up. Even .NET developers call into these same APIs pretty frequently and they face the same issue. If you take a look at PInvoke.net[^], .NET developers have come up with declarations allowing the Windows API to be called from their code. These declarations use the
IntPtrtype over and over again for all sorts of different things. So, even these .NET developers have to deal with the inherent problems that led to Hungarian notation. They don't seem to use Hungarian notation as much as people who do Windows programming in C, but the issues that led to it are still there. -
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.
That is my preference, and obviously it has a lot of support since Refactor recommends. As far as significant problem, those are your words, not mine.
-
Yeah, that's what I meant. So many things that are really different seem the same to the compiler when calling the Windows APIs. This has never really been cleaned up. Even .NET developers call into these same APIs pretty frequently and they face the same issue. If you take a look at PInvoke.net[^], .NET developers have come up with declarations allowing the Windows API to be called from their code. These declarations use the
IntPtrtype over and over again for all sorts of different things. So, even these .NET developers have to deal with the inherent problems that led to Hungarian notation. They don't seem to use Hungarian notation as much as people who do Windows programming in C, but the issues that led to it are still there._beauw_ wrote:
This has never really been cleaned up. Even .NET developers call into these same APIs pretty frequently and they face the same issue. If you take a look at PInvoke.net[^], .NET developers have come up with declarations allowing the Windows API to be called from their code. These declarations use the
IntPtrtype over and over again for all sorts of different things.Not exactly sure what you are referring to but I suspect a majority of C# developers never use pinvoke. And of the remainder that do many do not use it frequently. And I would like to think that of those that do use it frequently (and unfrequently) that they wrap it in a C# API of their own creation. Thus there would not be any more ambiguity in the usage for them or others at that point.
-
_beauw_ wrote:
This has never really been cleaned up. Even .NET developers call into these same APIs pretty frequently and they face the same issue. If you take a look at PInvoke.net[^], .NET developers have come up with declarations allowing the Windows API to be called from their code. These declarations use the
IntPtrtype over and over again for all sorts of different things.Not exactly sure what you are referring to but I suspect a majority of C# developers never use pinvoke. And of the remainder that do many do not use it frequently. And I would like to think that of those that do use it frequently (and unfrequently) that they wrap it in a C# API of their own creation. Thus there would not be any more ambiguity in the usage for them or others at that point.
I'm a .NET developer; in fact, it's my main job right now. I don't use PInvoke all that frequently, but I probably do use it (i.e. use the Windows API) more than any other API besides the .NET Framework itself. Yes, I do wrap up those low-level calls pretty frequently. I have to write the wrapper, though, and in doing that I face all of those same old issues of weak typing. Besides that, PInvoke is just part of the story. The larger issue (in my opinion, at least) is that the APIs themselves still are constructed and declared in this way. When Microsoft comes out with something new, like DWM for example, they basically construct its API similarly to the way they always have. Here are some examples from the DWM header file (DWMAPI.H):
DWMAPI DwmSetWindowAttribute(HWND, DWORD, LPCVOID, DWORD);
DWMAPI DwmExtendFrameIntoClientArea(HWND,const MARGINS*);Looking at that sort of thing, I do not perceive that the way in which Microsoft declares their API functions has changed all that much. They are still using
HWND, for example, which is really just another integer to the compiler. Is this why people are using Hungarian Notation? Yes, it is for some of them. For others, Hungarian Notation is a habit, or just something they picked up from others, and I agree that that's really pretty silly. -
I'm a .NET developer; in fact, it's my main job right now. I don't use PInvoke all that frequently, but I probably do use it (i.e. use the Windows API) more than any other API besides the .NET Framework itself. Yes, I do wrap up those low-level calls pretty frequently. I have to write the wrapper, though, and in doing that I face all of those same old issues of weak typing. Besides that, PInvoke is just part of the story. The larger issue (in my opinion, at least) is that the APIs themselves still are constructed and declared in this way. When Microsoft comes out with something new, like DWM for example, they basically construct its API similarly to the way they always have. Here are some examples from the DWM header file (DWMAPI.H):
DWMAPI DwmSetWindowAttribute(HWND, DWORD, LPCVOID, DWORD);
DWMAPI DwmExtendFrameIntoClientArea(HWND,const MARGINS*);Looking at that sort of thing, I do not perceive that the way in which Microsoft declares their API functions has changed all that much. They are still using
HWND, for example, which is really just another integer to the compiler. Is this why people are using Hungarian Notation? Yes, it is for some of them. For others, Hungarian Notation is a habit, or just something they picked up from others, and I agree that that's really pretty silly._beauw_ wrote:
I'm a .NET developer; in fact, it's my main job right now. I don't use PInvoke all that frequently, but I probably do use it (i.e. use the Windows API) more than any other API besides the .NET Framework itself. Yes, I do wrap up those low-level calls pretty frequently. I have to write the wrapper, though, and in doing that I face all of those same old issues of weak typing.
When you write a wrapper you are using a new API method of which you must become very familar. Thus you will be using a source (documentation) that tells you the exactly what information is needed. Thus there can be no benifit to you using hungarian notation at that time because you are using the documentation itself. Subsequent to that you use your wrapper API. And your wrapper API (unless you did it wrong) is strongly typed. You don't use the pinvoke API at all. So hungarian notation has no benefit in this context. If you, or someone else needs to maintain the pinvoke code later then they are, again, going to need to use the API documentation. Otherwise there is no point in maintaining the code. The above is a representation of usage scenarios if the a pinvoke API is wrapped rather than just used. If it is not wrapped then type usage is more of a problem however the real problem is that the API is not correctly wrapped.
_beauw_ wrote:
Here are some examples from the DWM header file (DWMAPI.H):
What does that have to do with anything? But if you want to use that API - then wrap it. And then it falls into exactly what I said above.
-
That is my preference, and obviously it has a lot of support since Refactor recommends. As far as significant problem, those are your words, not mine.
Clifford Nelson wrote:
That is my preference,
There is however a difference between expressing an opinion and attempting to rationalize that as being the best way.
Clifford Nelson wrote:
and obviously it has a lot of support since Refactor recommends
That of course is a rationalization. Unless of course you have some data that backs up with a survey of a large number of people.
Clifford Nelson wrote:
As far as significant problem, those are your words, not mine.
Nope. You said "Makes them easy to find, and you know they are private class level". So obviously that is your problem which you find this useful to solve. Myself I don't have that problem. I know which variables are class and local. So I don't need to solve a problem because none exists.