Hungarian Notation vs. IntelliSense
-
All true. I don't use Visual Assist (shame on me, I know), but I do use the 'p', 'm_', 'g_', 'n', 'sz' prefixes. Unlike some of the sxuggestions in the guide to Hungarian Notation in MSDN I don't absolutely mad and notate absolutely everything about a variable. > Andrew.
Same here.
-
Aside from Hungarian (I do like the m_ notation), I like to name parameters with a trailing underscore.
void MyClass::BigFunction(int nValue_)
{
// ... reams of code
m_nValue = nValue_; // trailing '_' helps me remember that
// nValue_ is a parameter, not a local
// variable.
}Parameters are local variables.
-
The purpose of Hungarian notation is to include the variable's type in its name so programmers know the type whenever the variable is used. Have any of you using Visual C++ 6 hovered the cursor over a variable? Henry casually scans the room searching a fire extinguisher.
Hi, Some of us have to compile our C++ code on: Windows, UNIX, VMS, AS400, Tandem and MVS. And my mouse don't fly ;) Old Simon
-
I used to love Hungarian notation, but the MSDN is proof of it's inadequacies. How many basic types have changed ( wParam for example ) and now have names that imply they are something they are not ? I always use p for a pointer, otherwise I find it to be of no value. Visual Assist tells me what type a variable is anyhow, and I have no use for looking over source code on paper, where I cannot edit it if I want to. Christian #include "std_disclaimer.h" People who love sausage and respect the law should never watch either one being made. The things that come to those who wait are usually the things left by those who got there first.
Some of the worst C++ I have seen is in the MFC source and to a lesser extent on MSDN, but to be fair quite a lot of it is quite old. Then again, if you want poor code just look at SAP (on second thoughts, better not - it's very depressing). Old Simon
-
... And of course, it's even harder to use this->nValue = nValue; ;) I personally don't like Hungarian Notation, but it's almost a standard in Win32 programming. What I hate the most is the Win32 typedefs like: LPCTSTR, LPTSTR, LPxxx etc. X|
What I hate the most is the Win32 typedefs like: LPCTSTR, LPTSTR, LPxxx etc. Why? They are obvious? Old Simon
-
I think Mike Dunn wrote a shell extension for that. :-D
What more can I say but... ROFL! ;P Andy Metcalfe - Sonardyne International Ltd
(andy.metcalfe@lineone.net)
http://www.resorg.co.uk"I used to be a medieval re-enactor, but I'm (nearly) alright now..."
-
What I hate the most is the Win32 typedefs like: LPCTSTR, LPTSTR, LPxxx etc. Why? They are obvious? Old Simon
The L is the annoying bit for me, since it's a legacy thing from 16 bit days. Of cource you could argue that it'll have a second wind with win64...
-
The L is the annoying bit for me, since it's a legacy thing from 16 bit days. Of cource you could argue that it'll have a second wind with win64...
I dropped the "l" prefix when I started with VC 4.0. Most of the others still make sense though I do get irritated that Win32 and MFC use different prefixes! Andy Metcalfe - Sonardyne International Ltd
(andy.metcalfe@lineone.net)
http://www.resorg.co.uk"I used to be a medieval re-enactor, but I'm (nearly) alright now..."
-
Are you using PAPER.NET? ;)
-
One reason I use the "m_":
void MyClass::SetValue(int nValue)
{
m_nValue = nValue;
}If I didn't use the 'm_' I'd have to think of different names for the member variable and the parameter. WAY too hard ;) cheers, Chris Maunder
Hello Chris, what about this.nValue = nValue :)
-
Hello Chris, what about this.nValue = nValue :)
Uh Oh, should have been this->nValue = nValue:| :|
-
Sounds like you're taking a sensible approach - doing it when it makes sense instead of because it's the 'done thing'. Christian #include "std_disclaimer.h" People who love sausage and respect the law should never watch either one being made. The things that come to those who wait are usually the things left by those who got there first.
Yeah, same with me. I use Hungarian notation as a tool, not a religion. I have looked at some of my old code with H-N and some of my old code without it. I was able work with the H-N code faster and get my job done faster. So I use it. It is simple as that. Tim Smith Descartes Systems Sciences, Inc.
-
One more aspect of naming, it's easy to look at lists of names (for instance in a .map file or dumpbin output) and tell what's what. You can always use
UndecorateName()to get some of this information but it's incomplete and inconvenient. It's good to be able to grep through code and such for global variables, member attributes, functions, local variables, function arguments, etc. Thus, I get most mileage from the stuff before the underscore (I usem_,s_(static member),g_(global),sc_(static const member),gc_(const global), and (rarely)mc_(const member)). I have gotten in the habit of using Hungarian everywhere because it helped me out when I was first writing Windows code, but it is much less useful to me now. More of a bad habit that I haven't broken or learned to moderate (is there a local chapter of Hungarians Anonymous in Tennessee? :-)).I also used HN when I started programming Windows but have since stopped. I still use g_ and m_ though.
-
Uh Oh, should have been this->nValue = nValue:| :|
I really don't like this particular style. I just don't find it clear. One of our (former) developers used to use this->SomeFunction() to force Intellisense to display the members of the class while he was coding (he hadn't discovered CTRL+SPACE). Everybody on the team used to hate reading his code. Just one of them things I guess - in his own words "much badness" X| Andy Metcalfe - Sonardyne International Ltd
(andy.metcalfe@lineone.net)
http://www.resorg.co.uk"I used to be a medieval re-enactor, but I'm (nearly) alright now..."
-
IntelliSense only works about 50% of the time for me. the other 50% it's either wrong or unresponsive. So, it's essentially useless since you don't know if you've mispelled a variable name or if IntelliSense is just sleeping again. Hungarian should be the 11th Commandment: In statically typed languages, thou shalt use a name that describes the variable's type. -c ------------------------------ Smaller Animals Software, Inc. http://www.smalleranimals.com
I agree.. And Command Completion via ctrl-space works about 20% of the time. It seems to never know the scope of the variables I'm using because It appears to be doing preprocessing (checking the syntax) and of course while I'm typing a statement and it is not complete it is a syntax error... And for Intellisense, I experience the same unresponsive behavior, its not the speed of my pc. My primary development machine is a new 900 Mhz Athlon Win2k box with 512MB of memory and 45GB of harddisk space with 20GB free. John
-
I agree.. And Command Completion via ctrl-space works about 20% of the time. It seems to never know the scope of the variables I'm using because It appears to be doing preprocessing (checking the syntax) and of course while I'm typing a statement and it is not complete it is a syntax error... And for Intellisense, I experience the same unresponsive behavior, its not the speed of my pc. My primary development machine is a new 900 Mhz Athlon Win2k box with 512MB of memory and 45GB of harddisk space with 20GB free. John
This is why I use VisualAssist. John
-
Parameters are local variables.
Parameters are local variables. Not in all respects. When a parameter is passed by reference, there are side effects to assigning to it. I need to worry about whether auto variables within a function have been initialized, but I can assume that a parameter has been initialized. When a pointer is passed in, I want to treat it differently than if I have assigned it locally. For all of these reasons, it's helpful to me to keep the two kinds of variables straight in my mind and I find it useful to make them lexicographically distinct. I understand that not everyone may find this useful. That's fine.