What's the story with Hungarian Notation these days?
-
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
-
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).
My guess is that the one's who've actually thought about it feel it's better to keep the code-base consistent than to switch notation, even if the original reason for choosing the notation is no longer valid. The rest probably don't care and continue following habit.
Sort of a cross between Lawrence of Arabia and Dilbert.[^]
-Or-
A Dead ringer for Kate Winslett[^] -
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
Ennis Ray Lynch, Jr. wrote:
you don't need an underscore.
You don't need it (or any other naming convention for that matter). Leading underscores are written to immediately identify a variable as being
privateto that class (vs. a local). /raviMy new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
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
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).
-
Ennis Ray Lynch, Jr. wrote:
you don't need an underscore.
You don't need it (or any other naming convention for that matter). Leading underscores are written to immediately identify a variable as being
privateto that class (vs. a local). /raviMy new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
Ravi Bhavnani wrote:
Leading underscores are written to immediately identify a variable as being
privateto that class (vs. a local).That convention is common in Python, except Python doesn't actually have private members, so an underscore is really just saying "Please don't use this...pretty please?".
-
Ravi Bhavnani wrote:
Leading underscores are written to immediately identify a variable as being
privateto that class (vs. a local).That convention is common in Python, except Python doesn't actually have private members, so an underscore is really just saying "Please don't use this...pretty please?".
And in Google Closure, trailing underscores are used to identify private fields! /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
And in Google Closure, trailing underscores are used to identify private fields! /ravi
My 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'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
-
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
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.
-
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 (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.
-
That sounds inconvenient...I like typing underscore and getting a list of private members, and when looking at a list being able to quickly identify them. That breaks the former and makes the latter harder. :doh:
True. :( /ravi
My 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 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
-
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 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. wrote:
you don't need an underscore.
You don't need it (or any other naming convention for that matter). Leading underscores are written to immediately identify a variable as being
privateto that class (vs. a local). /raviMy new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
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
-
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.
