What's the story with Hungarian Notation these days?

Septimus Hedgehog

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).

Ennis Ray Lynch Jr

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

Nemanja Trifunovic

PHS241 wrote:

Just about every bit of C++ code I've seen is written using Hungarian Notation

You are probably looking at Win32/MFC based code only. Out of these areas, Hungarian was never popular among C++ developers.

utf8-cpp

lewax00

I use the underscore for stuff like that in C#, just to imitate the compiler. Which is really not a good reason now that I actually think about it.

Keith Barrow

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[^]

Ravi Bhavnani

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 private to that class (vs. a local). /ravi

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

Septimus Hedgehog

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).

lewax00

Ravi Bhavnani wrote:

Leading underscores are written to immediately identify a variable as being private to 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

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

lewax00

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:

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