Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

myVariable vs lcMyVariable 1

Status
Not open for further replies.

tvign

Programmer
May 16, 2003
50
US
An Opinion.

The cusotm of craeintg varalbie nemas preedecd by ltteres to idicnate tiher scpoe and tpye mekas pagrroms hrad to raed. As you can see, the hmuan mnid can raed any txet pvrodinig all wodrs bgien and end wtih the coerrct leetrts. Wehn the msot imorpantt wodrs bigen wtih 'lc', 'ln', 'll', etc., the hmuan mnid cnnaot compreenhd. Copmreenhsion of the atirglhom is mroe ipmtoanrt tahn woindreng aubot the socpe and tpye of the vaarbeils uesd to dceisrbe the aotirhlgm.

Note: I'm not looking for a response to this, since this an age old debate. However, Computer Science is a branch of Mathematics and algorithms are mathematical entities and should be simple and elegant.

Tony

 
poAs pnYou lcCan lcSee, ltThe toHmuan tcMnid tdCan ptRaed gtAny gcTxet tcPvrodinig lcAll lcWodrs tcBgien toAnd toEnd ltWtih tcThe pdCoerrct tcCpatial plLeetrts. tlWehn tcThe tdMsot llImorpantt ltWodrs lcBigen pcWtih 'lc', 'ln', 'll', pcEtc., llThe tlHmuan plMnid tcCrtiatelny lcCan gtCompreenhd.

- Bill

Get the best answers to your questions -- See FAQ481-4875.
 
I see and I appreciate your response. However,removing the first two letters...

"As You Can See, The Hmuan Mnid Can Raed Any Txet Pvrodinig All Wodrs Bgien And End Wtih The Coerrct Cpatial Leetrts. Wehn The Msot Imorpantt Wodrs Bigen Wtih 'lc', 'ln', 'll', Etc., The Hmuan Mnid Crtiatelny Can Compreenhd."

Try reading both. Then tell me, again, in what world would you prefer to be living?

Tony

 
I'd prefer to be in living in the world of self-documenting code. To that end, Hungarian Notation is an invaluable tool. IMHO, it is a disservice to both the current and future developers to forego this useful naming convention. I would respectfully argue that Hungarian Notation makes code more readable, not less. Your example paragraph misses the mark as it is not code... consider the following snippet...

X = Y + Z.Something

...not sure if this is mathematical addition or string concatenation? And what about Z, is it an Alias.Field or SomeObject.Property? (it's neither, it's a form method actually)

lcX = gcY + frmZ.Something()

...a wealth of information is now apparent. Take it a step further and the code is even better...

lcFullPath = gcAppDefaultPath + frmBrowseDir.GetFileName()

It's clear to see that using a form of Hungarian Notation, Camel Case, and providing the "()" even though it isn't necessary have all conspired to make this code much more readable. Couple these elements with a few well placed comments and you've greatly increased the maintainability of your code as well as it's value.

For those interested in some good suggestions for naming conventions in VFP, there is a section in the VFP Help File aptly named "Naming Conventions" with sections on objects, variables, tables, and more.

boyd.gif

 

I used to hate this so-called Hungarian notation, and never used it myself. Like Tony, I felt that the two initial lower-case letters detracted from readability and wasted bandwidth.

However, I was once forced to use it on a project, and soon began to appreciate its value. Just to be able tell at a glance if a given value is a local variable or table field or whatever is really useful. It would, of course, be even more useful if the compiler could enforce it, but that would be against the concept of loose typing.

The only thing I still don't like about it is the term "Hungarian notation". Does anyone know how that arose? I feel sure that there has never been any connection between this convention and Hungary or Hungarians.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My sites:
Visual FoxPro (www.ml-consult.demon.co.uk)
Crystal Reports (www.ml-crystal.com)
 
The source Wikipedia article (practically Identical):
From the more direct article :
Origin

Hungarian notation was invented by Charles Simonyi, a programmer working at Xerox, who later became Chief Architect at Microsoft. The name comes from Simonyi's nation of origin, and was also probably inspired by the name of an unrelated concept, Polish notation. The term Hungarian notation is memorable for many people because the strings of unpronounceable consonants vaguely resemble the consonant-rich orthography of some Eastern European languages.

- Bill

Get the best answers to your questions -- See FAQ481-4875.
 
...It came to be known as "Hungarian notation" because the prefixes make the variable names look a bit as though they're written in some non-English language and because Simonyi is originally from Hungary."

I like work. It fascinates me. I can sit and look at it for hours...
 
An interesting page explaining (very convincingly, to C programmers) the value of such notation (this is an external link on one of the wikipedia pages):
- Bill

Get the best answers to your questions -- See FAQ481-4875.
 
Sorry, I can't resist another post. In a weakly-typed language such as VFP, I fully endorse traditional "Hungarian Notation" because I've fixed numerous bugs that would have been more easily caught/avoided if the varible types had been clearer.

However, surprisingly, as I finished reading the article I posted a link to above (again, ), "Traditional Hungarian Notation" was not Simonyi's original intent...

Excerpts (emphasis mine):
Simonyi’s original concept for Hungarian notation was called, inside Microsoft, Apps Hungarian, because it was used in the Applications Division, to wit, Word and Excel. In Excel’s source code you see a lot of rw and col and when you see those you know that they refer to rows and columns. Yep, they’re both integers, but it never makes sense to assign between them. In Word, I'm told, you see a lot of xl and xw, where xl means “horizontal coordinates relative to the layout” and xw means “horizontal coordinates relative to the window.”
. . .

But then something kind of wrong happened.

The dark side took over Hungarian Notation.

Nobody seems to know why or how, but it appears that the documentation writers on the Windows team inadvertently invented what came to be known as Systems Hungarian.

Somebody, somewhere, read Simonyi’s paper, where he used the word “type,” and thought he meant type, like class, like in a type system, like the type checking that the compiler does. He did not. He explained very carefully exactly what he meant by the word “type,” but it didn’t help. The damage was done.

. . .

Systems Hungarian was promulgated far and wide; it is the standard throughout the Windows programming documentation; it was spread extensively by books like Charles Petzold’s Programming Windows, the bible for learning Windows programming, and it rapidly became the dominant form of Hungarian, even inside Microsoft,...

. . .

And then came The Great Rebellion. Eventually, programmers who never understood Hungarian in the first place noticed that the misunderstood subset they were using was Pretty Dang Annoying and Well-Nigh Useless, and they revolted against it.

. . .

The Great Rebellion hit its peak with the first release of .NET. Microsoft finally started telling people, “Hungarian Notation Is Not Recommended.” There was much rejoicing. I don’t even think they bothered saying why.


I hope these quotes don't discourage reading the whole article, but, instead, whet your appetite for an interesting read which can help us all to write better self-documenting code. (interestingly to me, VFP-style naming seems closer to original/Apps Hungarian than the more recent. Also, I feel reassured that, in my forays into accessing the Windows API, that, yes, DWORD really is the same as Unsigned Long...)

- Bill

Get the best answers to your questions -- See FAQ481-4875.
 
I didn't mean to start a debate. You are all correct from a programming point of view with regard to the laborious task of maintaining code, even someone else's. Craig Boyd pointed that out with much clarity.

I'm a mathematician and to me elegance is more important. Try reading E. Dijkstra sometime and enjoy in the beauty.

Again, only an opinion. To me, lnE= pnM*gnC^2 is not immediately obvious. (Sorry, Albert, for that.)

I wouldn't want to use Hungarian Notation for the following functions that describe chaos...

Code:
function f(x) 
return 4*lamda*x*(1-x)
*---------------- 
function g(x)    && 1st iterate of f 
return f(f(x))   && 1st iterate of f
*---------------- 
function h(x)    && 2nd iterate of f   f(f(f(f 
return g(g(x))   && 2nd iterate of f   f(f(f(f
*---------------- 
function k(x)    && 3rd iterate of f   f(f(f(f(f(f(f(f 
return h(h(x))   && 3rd iterate of f   f(f(f(f(f(f(f(f
*----------------

Tony
 
Hola amigos: Para la mayoría de ustedes es difícil leer este mensaje en español; por eso la Notación Húngara nos facilita la comprensión de los programas como un lenguaje universal. Algo así como el idioma inglés: todos nos comunicamos mejor con el.

Hello folks: It´s so hard to read this spanish message for the most of you; the Hungarian Notation makes easier to understand code as an universal language. It´s like the English: we all comunicate better with it.

Germán Restrepo
Bogotá, Colombia
 
Good point, Germán: I've read many code samples with all spanish or french variable names ( I speak neither Spanish, nor French ), and could relatively easily make sense of them because of the Hungarian Notation. I've read other samples (without it) and gave up.


Tony: As for starting a debate... that's what a forum is for, isn't it? ;) Really, I don't think any of us are getting "heated up" over it... it has been debated over and over.

It's just irresistable!

I think it all comes down to context: From different points of view, and very different applications, different naming conventions seem to make things easier. A routine implementing math certainly looks more "mathy" using x, y and z as variables (just don't get burned by the "m-dot" issue: ), but a routine involving complicated manipulation of data from databases, and calls to Windows APIs are a completely different situation.

It also seems to me that the shorter a routine (visually), the simpler the variable names can be, while still being understandable. Your example chaos functions are so short, and have so few variables, that there is little ambiguity. (however put function "h" in the middle of a program with 1000 other functions, and, what does "h" mean again?....)

It's interesting that it seems that VFP reduces all functions and variables to an integer to identify them, so shorter names only save time typing, and waste time figuring them out, but don't affect execution or .exe/.fxp size at all (except when debug info is "on", I guess): ... I can't find an URL for a description I was reading a couple weeks ago... sorry.

- Bill

Get the best answers to your questions -- See FAQ481-4875.
 
Bill,

I appreciate you input. When I do 'mathy' things, I prefer standard math/science variable names (v velocity, m mass, theta angle, etc.)
But you are right when we are in the database manipulation arena.
And, thanks for reminding me about the m-dot issue.

Tony
 

Tony,

I prefer standard math/science variable names (v velocity, m mass, theta angle, etc.)

Isn't it a question of the number of variables and the complexity of the idea/

Einstein would never have written:

energy = mass * speed of light ^ 2

because it wasn't necessary. Anyone who understood what he was saying would have no difficulty remembering the variables E, m and c (OK, I know c is a constant, not a variable, but that's not the point).

But if he had to write 5,000 lines of code to express his theory, including several hundred variables, I'll be he would have come up with a better naming convention.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My sites:
Visual FoxPro (www.ml-consult.demon.co.uk)
Crystal Reports (www.ml-crystal.com)
 
Mike
But if he had to write 5,000 lines of code to express his theory
But, he didn't. That's the idea. No program part (subroutine or function, with it's local variables) need be more than half a page. If it is, then good structured and object oriented programming practices are being violated. I cant imagine that you are coding a method with 5000 lines of code without breaking in down to managable parts!

Elegance and simplicity is the key to managable programs, algorithms and ideas.

Tony
 

Tony,

No program part (subroutine or function, with it's local variables) need be more than half a page.

Of course, that's right (well, it depends on how you define a page, but let's not get into that).

My point was that, when you read a program, you need to take in a lot more information than if you are looking at a single mathematical expression. It makes no difference whether or not the program is split into neat self-contained modules. You still have a large number of separate variables to absorb and keep track of.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My sites:
Visual FoxPro (www.ml-consult.demon.co.uk)
Crystal Reports (www.ml-crystal.com)
 
Mike,

Point taken. However, when I'm reading a mathematical proof or the derivation of a economics law, there are many lines...with no Hungarian or other derived notation except the standard, universally accepted, variable names and local ones. The local ones are usually defined at the beginning just as we do with LOCAL and PRIVATE.

I'd rather see...
local firstVar,otherVar
* where firstVar is a number in range [2:reccount()] and...
* otherVar is a filename with extention DBF

...than
local lnFirstVar,lcOtherVar

I see little difference between math, physics, economics, etc. and computer science. Each should have a relatively common language and structure.


I think we can go on forever, but I respect you view.

Tony
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top