Discussion on:

Improve your technique: Take advantage of JavaScript coding guidelines

Kind of ironic that the lead article in todays newsletter was on speeding up your web site by eliminating "whitespace" and comment tags.
I tend to side with this Author on the white space and with M.Meadhra on removing the comments, with one caveat; I always print out the completed work with comments, prior to removing them when I post the page to the website.

Putting 3 letters before vars to indicate var type was invented(?) by hungarian microsoft's coder Greg Reddick. Sometimes it is called hungarian notation.

It was meant to avoid misassigning a bigger content to a small var in programs written in C language. Everydude knows that C is typeless when dealing with pointers, which causes memory leaks, memory corruption, and increases the ozone hole (yep, they didn't want you to know that).

say:

//danger,will robinson. danger
intTheInt = 12.234;
*puintMemoryAddress = intTheInt;

this is obviously wrong. I can see that i'm trying to assign a long to integer, the notation helps me to visualize that. But it's a valid C code.

why hungarian notation is useless in javascript (script languages), or java, or pascal (delphi)??

Answer: none of them uses pointers!

If you assign the wrong type to Java you got a compiler msg "wrong type...", and you fix it.

If you are using a script language you don't get anything, they run silently.

Furthermore, if later you decide to change var type from integer to long you have to rename all vars in all files (easy if you use Vim).

So save yourself some typing and forget Hungarian Notation.

"It was meant to avoid misassigning a bigger content to a small var in programs written in C language. ..."

I have been using Hungarian notation for a few years and think there's a bit more to it than that. The link to the original paper by Charles Simonyi (founder of Hungarian notation, not Reddick) is:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvsgen/html/hunganotat.asp

Taken from this paper, here are the objectives the Hungarian notation strives to meet:
-----
1. Mnemonic value?so that the programmer can remember the name.
2. Suggestive value?so that others can read the code.
3. "Consistency"?this is often viewed as an aesthetic idea, yet it also has to do with the information efficiency of the program text. Roughly speaking, we want similar names for similar quantities.
4. Speed of the decision?we cannot spend too much time pondering the name of a single quantity, nor is there time for typing and editing extremely long variable names.
-----

Naming conventions are always a controversial issue. Most people seem to be on one side or the other; not many are ambivalent. I was reluctant to change my precious style at first, but now I would hate to go back.

Hungarian notation has helped me read people's code in VB, but it is most useful in script where strong datatypes don't exist. I find that good developers which don't use the prefixes of Hungarian notation wind up adding suffixes instead. (ie. "menuDiv" instead of "divMenu") The bad developers, on the other hand, slip and just put "menu". I prefer to have a simple convention that offers consistency for the good developers and more self-documenting code from the others.

Note also that the hungarian notation has provisions to name variables of different scope which helps to avoid naming conflicts and improves readablility of code.

Bravo! The use of Simonyi's Hungarian Notation is one of the marks of a good programmer. I couldn't agree more or have put it any better.

OK, one comment: weakly typed languages (like JavaScript) gain even more from HN than strongly typed ones (like Java) precicely because the compiler won't balk at mis-assignments.

I use the so-called "hungarian notation" primarly for visual controls such as buttons, checkboxes, etc.
It is a lot clear to me when I have objects named:
btnOK, chkDeliver, pnlAsk

instead of just:
OK, Deliver, Ask

It's a lot more clear what we're talking about in the first example.

For basic type variables such as string, integer, etc. I don't use this notation though.

In an OO Programming language, basic type variables should always be kept to a minimum, and their name can be descriptive enough as not to use hungarian notation.
(Globals should be kept down to zero use)

"Is it easier to figure out the purpose of a variable named account_balance or ab?" - while ab certainly can be too short, would anyone really have any trouble guessing the meaning of acct_bal? While I agree that avoiding single character variable names is wise, I feel that abbreviations should be used as long as the meaning is clear. No one really wants to type or read 'balance' when 'bal' will do just as well.

I, in fact, prefer to type and read Balance instead of bal. I've found it takes some time for people to get used to (sometimes years) but virtually everyone prefers it in the end (maybe they're just older and more forgetful I don't know!!!).

Hungarian Notation is really anti-OO because the type of the variable really should be unimportant (if you've used Smalltalk, a lot of JavaScript OO or other weakly typed/untyped you might have seen that).

What is of critical importance with OO is not "type" of the object but the interface of the object. If it responds to my message it shouldn't matter what type it is, what inheritance tree it is part of or anything else of that ilk.

I've heard many times that the official Microsoft (the original pushers of Hungarian Notation) now recommend you do NOT use it. They've put some of what I mentioned above in .Net using their Interface-based programming model. Although they still seem highly focused on strong typing.

My opinion is that uniformity and readability are both important and that different coding styles do lend themselves to better readability but the synapses that are built from uniformity are also very important.

David

It would be great to have an automatic documentation generation tool for Javascript too, like Java has (javadoc) and PHP (phpDocumentor). Does anyone know if something similiar to these tools exists?

Bojan Mihelac
http://www.mihelac.org

Although this article starts out stating that readability is the goal, the presented rules seem to address uniformity instead. Although it can be debated whether uniformity is valuable or not, I will address the issues of readability.

In practice, I have found that brace placement does not affect the readability of code. It is far more important to follow a good indentation practice and to limit the length of functions.

Likewise, I have found no benefit to Hungarian notation, but I have found no harm from it either. It is far more improtant to concentrate on the selection of the base name.

I have found little benefit in various variable and method naming conventions. I do not find value in attaching any signficance to whether the first character is upper or lower case. Likewise, I find little value in dictating "camel case" versus underscores, and find readability enhanced when developers use an appropriate mix of the two.

As for abbreviations, the best rule of thumb is to rely on the appropriate business language. If the users rely on an acronym, the code should reflect their usage. If the users rely on a spelled out term, the code should reflect that as well. This ties the intended use together with the functional operation.

One aside, the best rule I have seen for assigning variable names is to name them based on their intended uses, not based on their storage formats. For example, name a variable "FirstName" rather than "String." Often the usage will imply the storage type, but the storage type will never imply the usage.

People can adapt to a wide range of styles when reading code. A uniform style will not help make poorly laid out code more readable. I have yet to be confused about code merely because or where the author chose to put a brace or because of his choice of TABs or SPACEs. Concentrate on readability and don't waste time on enforcing uniformity.