|
|
In Windows platform, I use Hungarian notation with prefixes. But in Linux, I use c-style notation(because linux is case sensitive).
|
|
|
|
|
Madhu Kampurath wrote:
because linux is case sensitive
Are you implying the VC++ compiler isn't?
/ravi
My new year's resolution: 2048 x 1536
Home | Articles | Freeware | Music
ravib@ravib.com
|
|
|
|
|
Madhu Kampurath wrote:
in Linux, I use c-style notation(because linux is case sensitive).
so linux compiles ur code ?!? or the gcc or some compiler.
|
|
|
|
|
Can anyone explain to me why some folks including Microsoft are moving away from Hungarian to camel case (or camelCase)? I find Hungarian to be a superior way to annotate my code.
MCSE+I, MCSD, MCDBA
|
|
|
|
|
Phil Sidari wrote:
I find Hungarian to be a superior way to annotate my code.
So do the camelCase people, apparently.
--
My name in Katakana is ヨルゲン.
My name in German is Jörgen.
I blog too now[^]
|
|
|
|
|
C++ typesafety and Intellisense?
--
Meski
|
|
|
|
|
I am a C++ programmer and am a firm believer in Hungarian notation. I don't have an answer for you but I go to a weekly .NET Users group on the Redmond, WA. campus and the comments I have heard from some of the Microsoft employees and contractors there is that they are going away from Hungarian because of inconsistent use (sMyVar or strMyVar for strings, iMyVar or nMyVar for ints) and the improvements that have been made with intellisense.
I agree that it can be a nuisance to decipher someone's Hungarian but once you know the coding style it is nice to be able to quickly read the code without having to stop and wait for the intellisense to pop up showing the variable type.
-Tim
|
|
|
|
|
slimtim wrote:
[...] Microsoft employees and contractors there is that they are going away from Hungarian because of inconsistent use (sMyVar or strMyVar for strings, iMyVar or nMyVar for ints)
Sounds like lack of a consistently applied coding standard and/or guidelines to me. If you have to ask what it means, then it is not consistent or a standard by any means. Inconsistent use is usually not a problem with the standard itself, but with the development staff.
FWIW, my standard uses characters to modify a type, same as when you would declare it, which eliminates some ambigious prefixes, like u. Also, we do not use a prefix to indicate purpose. For example:
<br />
int iSomeVar = 0;<br />
short int siSomeOtherVar = 0;<br />
unsigned int uiStillSomeOtherVar = 0;<br />
DWORD dwValue = 0;<br />
DWORD *dwpAPointer = NULL;<br />
And not:
<br />
unsigned int uSomeVar = 0;<br />
short int sSomeOtherVar = 0;<br />
DWORD cbBufByteLen = 0;
Strings are prefixed with s unless we are using multiple kinds of string objects, like when using both CString and std::string for some reason:
<br />
CString sAString;<br />
CString csACString;<br />
std::string ssAnSTLString;<br />
I could not use Intellisense as an excuse for removing documentation, or not providing documentation, which, IMHO, is what you are doing by removing prefixes. Not everyone that is going to use your code is going to have Intellisense (or something like it).
Peace!
-=- James
If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Tip for new SUV drivers: Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
DeleteFXPFiles & CheckFavorites
|
|
|
|
|
You are spot on James! Great examples. I think you summed it up best by saying a lack of coding standards and/or guidleines.
Too bad there isn't a Hungarian Notation Cosortium similar to the W3C.
-Tim
|
|
|
|
|
Hungarian notation is a useful tool - when working in environments that do not enforce type checking (such as scripting languages, etc). Using a prefix can clue you in to what you expect the variable to contain.
In type enforced languages - the compiler will note when you have a type error. It's pretty easy to fix these little bugs so the type notation isn't needed. Also, variable scope should be small enough that it is easy to refer to the declaration, if needed.
However, Hungarian notation has a dark side - and that is that it flies right into the face of encapsulation and data hiding. Of course, there is the contradiction that C++ programmers are the most likely to be the ones using Hungarian notation. Variables should be named for what they represent and not by how they are implemented!
It's also a maintenance issue. In later revisions, a variable could be switched to a different type (that conforms to the semantics of the original type used) - only the declaration and constructor calls would need modification. If Hungarian notation was used - you would have to track down all of the now erroneous prefixes and change them.
I'm really glad that the next generation of programmers won't be seeing the apparent endorsement of this technique in books (at least for .NET).
Dale Thompson
|
|
|
|
|
Dale Thompson wrote:
It's also a maintenance issue.
Do you find it easier to read old code without hungarian notation?
Personally I come across too much code that is ambiguous without types.
|
|
|
|
|
PaulMdx wrote:
Do you find it easier to read old code without hungarian notation?
Personally I come across too much code that is ambiguous without types.
Dale's point was that in modern languages, there is no such thing as a variable without type. You're forced to choose a type.
And yes, I think that:
NumberOfUsersOnline
is easier to read than
gliNumberOfUsersOnline
or some of the even uglier examples.
|
|
|
|
|
BluePineNeedles wrote:
And yes, I think that: NumberOfUsersOnline is easier to read than gliNumberOfUsersOnline or some of the even uglier examples.
Well, the purpose of notations like (reverse) "Hungarian Notation" is not to make "something" easy to read - children's books are "easy to read". It is supposed to provide more information on what that "something" is and possibly how it used.
Yes, NumberOfUsersOnline is less characters and, to the untrained eye (i.e. your average everyday user), likely looks nicer than gliNumberOfUsersOnline. But looking at NumberOfUsersOnline provides me with no information on what it is (String, Integer, Floating Point?), and without that information readily available, you may have to waste additional resources just to figure out how and if you can use it.
IMHO, LTTLS1 is no longer a viable option given the amount and complexity of code being written these days.
Peace!
1: Look To The Left Stupid - A method of finding out a variable's type by looking to the left of its declaration, going through as many files as required to actually find it.
-=- James
If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Tip for new SUV drivers: Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
DeleteFXPFiles & CheckFavorites
|
|
|
|
|
James R. Twine wrote:
BluePineNeedles wrote:
And yes, I think that: NumberOfUsersOnline is easier to read than gliNumberOfUsersOnline or some of the even uglier examples.
Well, the purpose of notations like (reverse) "Hungarian Notation" is not to make "something" easy to read - children's books are "easy to read". It is supposed to provide more information on what that "something" is and possibly how it used.
Thanks James, my point exactly.
|
|
|
|
|
You have a point about easy to read vs informative, but I still think that if you're managing your variables' scope carefully (see composed method[^]) and you are using a language that enforces type, the need for hungarian notation diminishes to a point that its utility is less than its annoyance factor.
In fact, the primary motivation for moving toward a camelCase/PascalCase from hungarian (I suspect) is that the need to convey information about a variable has been overtaken by the need to concisely convey intent. The key here is that if we remove the scope+type prefix (or some combination thereof), then we don't have to deal with a great number of disparate naming conventions that follow hungarian around like a bad used car salesman at a car lot.
From personal experience, code monkeys in projects without hungarian spend much less time stressing about the naming convention and no more time stressing about type and scope than those on projects with hungarian conventions.
|
|
|
|
|
|
Personally i prefer to have somthing like this:
sStringName and iIntegerName
as opposed to
stringname and integername
i mainly use VB, VB.net, C#, C++, and ASM, but we are being taught Object Pascal at uni, (which i have come to Hate with Avengance) and the teachers and lab techs have no idea what a coding practice is. they decalre all variables with no casing (all lowercaps) and no prefixes, all controls have no prefixes, and you are luvky if they change the name, (they usually stick with Form1, Button1, Button2 etc). 
i also dislike it when people use capslock on all variables, i think it makes them hardfer to read.
- Andy
http://www.infinity.co.nr
http://www.casiofortissimo.co.nr
There are 10 types of people, those who can count in binary, and those who cant!
|
|
|
|
|
The main reason I started using camelCasing is because sometimes the variablenames get way to complex when you use the hongarian prefixes.
Maybe that's also the case for microsoft.
WM.
What about weapons of mass-construction?
|
|
|
|
|
Note: I posted this in the Lounge a couple of years back.
I used to think the same as you, and for years I used Hungarian notation. But here are some things to consider.
1. Chances are that for the most part, the code you're going to look at will be your own. That's been my experience at least; when working in a group, I spend most of the time looking at my own code.
2. Many times the type of the variable can be deduced by the name. For example, you wouldn't look at a variable called lastName and wonder what it's type is. How about a variable called evilGiraffes? The name implies that it's a collection of EvilGiraffe objects.
3. If you write your code in a modular fashion, delegating small tasks to individual methods, the variable's declaration and where it gets used will be in close proximity. So if you really need to know its type, it's nearby. Where it can become a problem is in really large methods, where the variable is declared somewhere at the top and you have to scroll to figure out its type. But I argue that these type of methods are few and far between. And besides, Visual Studio is pretty good about telling all about the variable when you hover over it.
4. Coming up with and keeping track of all the different prefixes can be a pain, and an even greater pain is enforcing it among a group of developers. If I now join your group and I prefer to use b instead bln for my booleans, it's gonna suck for me, and maybe for you too since I may forget to use bln and use b instead. So it's a lot easier to enforce the rule of "no prefixes". Now people just worry about what to call their variables and they don't need to also remember to tag it with the right prefix every time.
5. I don't remember where I read that prefixes suck if the variable type gets changed, since now you have to rename it. But that's not really a big deal, I don't think, since the Find/Replace box can take care of that pretty easily. Still, it could be noted as another point in favor of "no prefixes".
Regards,
Alvaro
You know what they say about arguing over the Internet...
|
|
|
|
|
First, I'm a C#/.NET programmer and my company uses VS.NET:
I use Hungarian for anything internal, and I like the camel case for parameters just for asthetics. When others are using my classes, the Intellisense shows them what the types are, and so for them to see SomeClass.Function(int iinput) is a little bit redundant.
Plus, I have to say I do find that in Hungarian notation, you still don't really know the type, unless it's your own code. For example, we use the SqlTypes when extracting information from the database, and the hungarian notation sivalue means short int to some and SqlInt32 to us.
JMHO.
Trevor
|
|
|
|
|
What annoys me is when a variable or a method name is misspelled (or is that misspelt???) You do a search on a something with the correct spelling, and no hits! WTF? Then you look at the code and realize someone couldn't spell. 
And if I ever encounter a variable like "gr8" I will kill that programmer! 
Marc
MyXaml
Advanced Unit Testing
YAPO
|
|
|
|
|
What is really hard for me, it's when the previous programmer does not share a common language, for instance the first one write variable name in romanian language, and the second one is spanish, and the last one is italian. Even you use camel/pascal/hungarian notations, you will be in trouble if they don't share a common speaking language.
Anyway, it's at least a little fun
take care
|
|
|
|
|
How whould You like variable names in Russian? As I see .NET supports any name including cyrillic. I had a view in a databse which named columns with Russian cyrillic name. VS tool had declared variables with cyrillic characters while was generating DataSet for that view.
|
|
|
|
|
Chill out, dood. U kant be l33t if u spel evrything rite.
Charlie
if(!curlies){ return; }
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
