|
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; }
|
|
|
|
|
I know a certain product, which has more spelling errors than not. I wish Mr Smith and Mr Wesson would meet the programmers behind it.
(No, I did not write any code for that product. I tried to read some.)
--
My name in Katakana is ヨルゲン.
My name in German is Jörgen.
I blog too now[^]
|
|
|
|
|
I have a library with an ExecuteScaler method (instead of ExecuteScalar). I wanted to change it when I first noticed it was wrong but I was scared at the prospect of having to find which other programs where using it and update them all. 
Everybody is entitled to my opinion
|
|
|
|
|
Marc Clifton wrote:
I ever encounter a variable like "gr8" I will kill that programmer!
And I'll be more than happy to provide the weapon. 
/ravi
My new year's resolution: 2048 x 1536
Home | Articles | Freeware | Music
ravib@ravib.com
|
|
|
|
|
I use camel caps, although until today I didn't know it had a name. 
Gary Kirkham
A working Program is one that has only unobserved bugs
He is no fool who gives what he cannot keep to gain what he cannot lose. - Jim Elliot
Me blog, You read
|
|
|
|
|
Gary Kirkham wrote:
A working Program is one that has only unobserved bugs
false. it is also an easy "debuggable" one...
TOXCCT >>> GEII power
[toxcct][VisualCalc]
|
|
|
|
|
toxcct wrote:
it is also an easy "debuggable" one
I am not sure what that means, however, if one of my programs has a bug then I don't know about it...because any bugs that ARE found are corrected immediately...and if my program has a known bug, then, by my definition, it is not a working program. So my statement is true based on my stipulations. I cannot evaluate your statement due to lack of understanding on my part.
Gary Kirkham
A working Program is one that has only unobserved bugs
He is no fool who gives what he cannot keep to gain what he cannot lose. - Jim Elliot
Me blog, You read
|
|
|
|
|
ok. two things...
imagine the case you develop a software, but not alone... you're in a big team, and you cannot do whatever you want 'cause the guys working with you won't understand what you tryied to do...
the second case is when you read back a project (of your own of not) to give it some updates... if you cannot read it, you just let like it is, or throw it to the "Windows Recycle-Bin"...
understand what i want to explain here ?!
TOXCCT >>> GEII power
[toxcct][VisualCalc]
|
|
|
|
|
Gary Kirkham wrote:
am not sure what that means, however, if one of my programs has a bug then I don't know about it...because any bugs that ARE found are corrected immediately...and if my program has a known bug, then, by my definition, it is not a working program. So my statement is true based on my stipulations. I cannot evaluate your statement due to lack of understanding on my part.
Not true! Some year ago I had a Medical billing program that worked correctly until I notice a bug and fix it... there was another bug that I didn't find at that time that acutally made the application work correctly. So two wrongs made a right and the buggy program was a working program!
|
|
|
|
|
Rick Crone wrote:
worked correctly until I notice a bug and fix it
If it worked correctly then it didn't have a bug. Why would you need to fix something that wasn't broken? By my definition, a bug is something that causes a program to not function as designed.
If the following if statement produces the correct results
if(x)
{
....
}
Is the following statement a bug?
if(!!x)
{
....
}
No
now, if I decide that the programmer got carried away and meant to have only one ! and I correct the "bug" by doing this
if(!x)
{
....
}
I have now created a bug that didn't exist before...now I have to "debug" it again
if(x)
{
....
}
The fact that your "Two Wrongs" program worked as designed doesn't necessarily mean it had bugs, maybe it just wasn't optimally coded. That is by my definition...you might consider a consistently misspelled variable name to be a "bug" and feel the need to correct it...I do not.
Gary Kirkham
A working Program is one that has only unobserved bugs
He is no fool who gives what he cannot keep to gain what he cannot lose. - Jim Elliot
Me blog, You read
|
|
|
|
|
|
|
|
i learned one thing... didn't know that my naming convention was Hungarian one...
i'm with you mike 
TOXCCT >>> GEII power
[toxcct][VisualCalc]
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
