|
I don't know why nobody uses the hongarian notation anymore. In my opinion, it is one of the more clear naming conventions around. Prefixing variables with their types (except for classes) just makes the code a little bit easier to understand. Besides that, all the this.someVar makes me feel weird. I know that many people like intellisense to pop up a list with members and such, but I just don't like all the blue in my code.
Besides that, using the cls naming convention requires more comment and / or documentation because the variable names are so unclear..
I wonder how other developers feel about that naming convention..
I also got the blogging virus..[^]
|
|
|
|
|
I must agree with you Bob. We currently use this convention and from the little that I have read about the CLS convention, it adds lots of useless and meaningless statments to the code. So to get to your code you actaully need to wade through loads of junk and comments before you actually get to the good stuff.
Bob Stanneveld wrote:
Besides that, all the this.someVar makes me feel weird. I know that many people like intellisense to pop up a list with members and such, but I just don't like all the blue in my code.
And now you take into account that various people might not have intellisense editors (gasp) and this.someVar is meaningless, is it a int, char, etc. Better to have this.m_iSomeVar , now we all know it is an int member variable, but wait we can't use an underscore, so that would be this.miSomeVar (which for me doesn't look as distinct as m_ does).
Also, what is wrong with unsigned variables?? I mean, if you know that you don't need the negative but you need the larger number, why is this wrong in CLS?
"Programming today is a race between software engineers striving to build bigger and
better idiot-proff programs, and the Universe trying to produce bigger and better idiots.
So far the Universe is winning." -- Rich Cook
|
|
|
|
|
RichardS wrote:
Also, what is wrong with unsigned variables?? I mean, if you know that you don't need the negative but you need the larger number, why is this wrong in CLS?
To be CLS-compliant your code must be consumable by all .NET languages. Unsigned variables are not. However, it should be OK to use them for private and internal code. They just shouldn't be in the public/protected interface.
Kevin
|
|
|
|
|
Yeah, well, which part of the .NET framework doesn't understand unsigned variables? As far as my knowledge goes, all languages support that primitive type...
I also got the blogging virus..[^]
|
|
|
|
|
No, they don't. I think only C# and C++ do. Maybe Delphi? Remember there are 20+ .NET languages.
Kevin
|
|
|
|
|
You mean 2 languages and 18 hanger's on.
(sorry - having some int/uint pain today. Bad CLS! Bad!)
cheers,
Chris Maunder
|
|
|
|
|
|
Hungarian Notation gets discussed in these forums all the time. I'm personally against it. Read my previous posts to see why:
Post 1[^]
Post 2[^]
Regards,
Alvaro
Victory means exit strategy, and it's important for the President to explain to us what the exit strategy is. -- GWB, 1999.
|
|
|
|
|
Alvaro, I'm the same as you in that I used to like Hungarian but now don't - pretty much for the reasons you cite. Also, like you I was forced not to use it and then found that I preferred it. My one concession to it is in class members where I think having a scope, not type, prefix improves readability. This would not matter so much if we all practiced the discipline of having short methods but we don't. An alternative to the scope prefixes though is to just qualify class members with the this reference. I also still use prefixes for controls. Though really instead of btnCustomer I should write customerButton.
Kevin
|
|
|
|
|
Like you Kevin, I also like the idea of distinguishing class fields (member variables) inside the code. However, I've been wavering back and forth on what's the best way to handle it consistently.
For a long time I went with "this.variable" in my Java code. Then I moved to .NET and came back to using "m_variable", like I had in the old MFC days. But then I got into ASP.NET and realized that it was a pain in the butt to keep all the variables generated in the codebehind files with the m_ prefix. So I once again dropped it and went back to "this.variable". After a while I realized that my methods were littered with "this.something" and "this.someOtherThing" and that it was actually making it more difficult to read -- everything had "this." in front of it so it was pretty much pointless.
These days I've gone with the "no freaking prefix" policy for my ASP.NET sources. If my form has an OK button, it's name is simply "ok". If it has a lastName textbox, it's name is "lastName", and that's how I use it in the code -- no "this.". Plain and simple.
For separate library source files, I've maintained the m_ prefix, which I still like, and it helps keep the code CLS compliant (the topic of this survey ).
Regards,
Alvaro
Victory means exit strategy, and it's important for the President to explain to us what the exit strategy is. -- GWB, 1999.
|
|
|
|
|
Which Hungarian Notation are we taking about?
I think that putting the type of a variable in the variable name as prefix is redundant (with Intellisense at least), but Apps Hungarian is meaningful in my opinion.
Joel Polsky on Hungarian[^]
Larry Osterman on Hungarian[^]
There are hundreds of 'standards' all called Hungarian, and some are definitely superior to others.
That said, a good IDE makes naming conventions less important. And writing lpszTtt to indicate a tooltiptext string is horrible.
|
|
|
|
|
I generally do not follow "hungarian notation" in it's strictest sense and I believe that aside from a "prefix" notation on the front of your variable it's also good to have a good descriptive name. However I follow a more moderate dialect that's briefly descriptive for certain variable types.
The prefixes that I generally tend to use would be:
"p" for pointer, I use this more commonly than the rest. The rest I use sparingly.
"dw" or "i" for dword or unsigned int, integer, generally to simply denote it's a number.
"sz" for NULL-Term string
"swz" for wide char
"uc" for unicode_string
"g_" for Global. I like to use the "_" because it's easier to search for it in the debugger as "G" itself can get you functions that start with "G". Now don't give me that you shouldn't use globals in programming, that's definately true when possible (and usually is possible) however sometimes globals can be useful for things like maintaining a debug state that doesn't directly interact with your program's logic.
I saw someone post in this thread that said that they don't use it because "they will be the only ones viewing the code" so I guess they do not have a job, at least not a real one...
|
|
|
|
|
Toby Opferman wrote:
I generally do not follow "hungarian notation" in it's strictest sense
I don't believe anybody does that, because then you'll have to prefix you function names with the parameters and return type! There goes the intended readability..
Toby Opferman wrote:
it's also good to have a good descriptive name.
That certainly is a good practice. I've seen to many student that write code like:
<br />
int a, b, c<br />
<br />
Not only will nobody know why the variables are there and what they are used for, but it just makes the code look ugly.
I also favor the prefix_ to indicate a variable that is used in more than one scope. But I make an exception for structs. These types should'nt have any member functions and therefore you can omit the scope prefix, because you don't have to distinguish between locals and member variables by the prefix, since the struct's variable name does it for you.
Toby Opferman wrote:
I saw someone post in this thread that said that they don't use it because "they will be the only ones viewing the code" so I guess they do not have a job, at least not a real one...
That certainly is a bad practice. Everyone should not test their own code and reviewing your code with others helps to improve things a lot..
I also got the blogging virus..[^]
|
|
|
|
|
Bob Stanneveld wrote:
hongarian notation
Hungarian?
[worldspawn]
|
|
|
|
|
Hallo,
I am not following hungarian. I am using my own naming convention.
first I name the scope, than the type, than the name like
privStrUserName,pubBolLockedIn something like this.
Personally I like it. Maybe I am oldfashioned.
Chris
Vietiane (Laos)
|
|
|
|
|
This is the convention I have been using since day one and have carried it across all languages that I code with.
|
|
|
|
|
The whole casing thing is a problem, and I've been bitten by other things as well. I tend to write CLS Compliant projects, and then when my code is not CLS compliant, it's knowingly so, I set the attribute to say I know and accept the fact.
I find though that I often have a camel case private variable, and a first letter uppercase property, and that's not CLS compliant, apparently. You can use _ for the first letter of a private variable, in fact CLS compliance suggests this. I don't like that though.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Christian Graus wrote:
I find though that I often have a camel case private variable, and a first letter uppercase property, and that's not CLS compliant, apparently.
I think the problem here is, e.g., VB. VB cannot understand a property defined this way because of case insensitivity. However, I'd have thought MS could have designed VB to cope with this. You can already have a type name and a variable name the same. Makes sense as they're in different namespaces.
Kevin
|
|
|
|
|
I dont see how you COULD write case insensitive code in C# or VC++
|
|
|
|
|
Case insensitivity means not having two identifiers in the same scope whose name differs only in case. It's easy enough to do this in the C-family languages and it's generally recommended anyway.
Kevin
|
|
|
|
|
My VB projects follows these rules:
1) Private vars with class scope:
Private mVarName As String
2) The properties that access them:
Public property VarName() As String
3) Vars with narrow (function level) scope
Dim varName As Integer
Never had a case of being confused....
George Carlin wrote:
"Don't sweat the petty things, and don't pet the sweaty things."
Jörgen Sigvardsson wrote:
If the physicists find a universal theory describing the laws of universe, I'm sure the a**hole constant will be an integral part of that theory.
My Blog[^]
|
|
|
|
|
Ray Cassick wrote:
Never had a case of being confused....
For once, this was not a VB bash. The problem I have is that the way I case variables, I am not CLS compliant. Because if I need a scratch variable, I am likely to do this:
Bitmap bitmap = CallSomeFunction();
And I can't do that, because VB is crap and does not recognise case. Oops, I guess it does relate to VB....
It also means I can't do properties like this:
Bitmap sourceImage;
public Bitmap SourceImage
{
get
{
return sourceImage;
}
}
For example.
Casing is one more place where VB won't hurt a disciplined programmer, but helps idiots write unreadable spagetti.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
I don't write dot net code, but I have been using underscore for my local variables for the longest time!
It seems like the rest of the industry is slowly catching up with me
|
|
|
|
|
Hate to break it to your exclusive future but: CLS-compliant means, among other things, no underscores in variable names
regards,
Paul Watson
South Africa
PMW Photography
Gary Wheeler wrote:
It's people like you that keep me heading for my big debut on CNN...
|
|
|
|
|
From what I read in this forum, it seems that this rule only applies to the public interface, does it not ?
So, my "local variable" have a even more "private" scope than the private attributes, for they are allocated on the stack, quite invisible from the interface standpoint.
|
|
|
|