|
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).
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
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?".
|
|
|
|
|
And in Google Closure, trailing underscores are used to identify private fields!
/ravi
|
|
|
|
|
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.
|
|
|
|
|
True.
/ravi
|
|
|
|
|
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.
|
|
|
|
|
IIRC, the Java convention is also to use m_ m .
/ravi
modified 16-Nov-12 16:29pm.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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"
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
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;
string z1 = (string) someInt;
int y2 = aStr as int;
string z2 = someInt as string;
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 like Telerik's JustCode, and AxTools' CodeSMART 10 with VS10x Extensions ... do offer this ?
And, I believe, consistent use of naming conventions, of whatever type, is essential for software teamwork. If I ever got another full-time job programming (perish the thought), and the team was using Hungarian; I'd go goulash; if they were using camelCase, I'd go hummus and baba ghannouj; if they were using "_m" consistenly, I'd eat M&M's
best, Bill
~
Confused by Windows 8 ? This may help: [ ^] !
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|