|
By Hungarian I mean the type is prefixed onto the variable name as in iCount, lpszName etc. The "m_", "p_", g_" etc. metaprefix indates the scope: Member of class, function parameter, global and so on.
Once upon a time we thought this was a good idea! But then incremental compilation meant we could go back to readable, pronounceable variable names.
(I'm waiting for the next generation retrospective on naming, when we go back to a maximum of six characters, and the first character defines it as a integer if it is 'i' to 'n' so you don't even have to declare them...)
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
|
|
|
|
|
OriginalGriff wrote: (I'm waiting for the next generation retrospective on naming, when we go back to a maximum of six characters, and the first character defines it as a integer if it is 'i' to 'n' so you don't even have to declare them...)
Good idea. Let us know when it is released
|
|
|
|
|
Don't remind me. I was downgraded by a professor for defining variables that just happened to start with i and j. Apparently, Pascal teaches you bad habits
|
|
|
|
|
rentzk wrote: Apparently, Pascal teaches you bad habits What do variable names like i and j have to with Pascal?
/ravi
|
|
|
|
|
Nothing that I remember: 'i' through 'n' inclusive being default declaration for integer, and the six character limit were FORTRAN.
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
|
|
|
|
|
Sorry, I was in a bit of a hurry. Pascal was where I was taught to always define my variables. This was not appreciated by a very old school instructor who taught the FORTRAN class. Fortunately, the Pascal lessons stuck with me a lot better than the FORTRAN ones.
|
|
|
|
|
The m_, g_ etc. prefixes are all later inventions MS added when they started writing MFC (I guess, that's the first usage I ever came across). You don't really need them in C as the only scopes are global, file and local.
|
|
|
|
|
That's where I first met Hungarian notation.
The only problem is I still use a bastardized version of it: tb for TextBox, but for Button, dgv for DateGridView...
One day, I must try to make a clean break!
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
|
|
|
|
|
You called?
Panic, Chaos, Destruction.
My work here is done.
or "Drink. Get drunk. Fall over." - P O'H
OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre
|
|
|
|
|
No, not you - your name doesn't start with a lower case letter, and is quite pronounceable.
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
|
|
|
|
|
His name is probably the only Hungarian name that CAN be pronounced. Man, do they know how to mess up names, or what?
--
Kein Mitleid Für Die Mehrheit
|
|
|
|
|
They say variety is the spice of life
There is such a thing as taking it too far, however.
Just because the code works, it doesn't mean that it is good code.
|
|
|
|
|
Maybe every piece of code comes from another on-line tutorial where various naming conventions were used. Better not to change anything if it works you know.
Greetings - Jacek
|
|
|
|
|
|
This Website calls for .Net hall of shame
=========[^]
sorry no code here posted.
|
|
|
|
|
"[Update: 18 November 2002: Microsoft have announced that a future version of C# will include support for anonymous methods.]"
The article must have been written against .net 1.0, when the framework was pretty immature compared to Java.
|
|
|
|
|
If c is blank do nothing, but still if c is blank, output blank array!!
Changing mind while coding!? and it is VBS
Function e1(c,outv)
ReDim outv(anc-1)
If c="" Then
Else
If c="" Then
For i=0 To ubound(outv)
outv(i)=""
Next
Else
x1=split(c,",")
For i=0 To ubound(x1)
If i<=ubound(outv) Then outv(i)=x1(i)
Next
End If
End If
End Function
|
|
|
|
|
I think examples like this provide an argument for making programming languages inherently complex - that way people would really have to learn their craft and it may weed out some of the f*wits who write this kind of drivel.
|
|
|
|
|
What's the licence? Can I use this in my own production code?
|
|
|
|
|
I think the horror may be that "anc" hasn't been defined and the code won't even get to the horror you mention...
I wasn't, now I am, then I won't be anymore.
|
|
|
|
|
"anc" is atleast defined outside.
|
|
|
|
|
At least that part is reassuring.
I wasn't, now I am, then I won't be anymore.
|
|
|
|
|
It's not all bad. At least the function doesn't need obfuscating
Architecture is extensible, code is minimal.
|
|
|
|
|
Obfuscating VBS?! I never thought that.
|
|
|
|
|
What I find deeply disturbing by this and other examples of bad coding is that these people get paid for writing this rubbish. Furthermore, what is more frightening is the fact that they could be writing code for safety systems or banking systems or who knows what else.
No bloody wonder the software industry puts a NO WARRANTIES EXPRESSED OR IMPLIED notice into every EULA They're not even sure it's going to work. Can you imagine buying a new car and the manufacturer said that there were no warranties?
Nobody can get the truth out of me because even I don't know what it is. I keep myself in a constant state of utter confusion. - Col. Flagg
|
|
|
|