Spolsky on Hungarian Notation

Posted by Thomas Gideon on 11 May 2005

I absolutely love Spolsky's essay, The Law of Leaky Abstractions. I would consider that a classic that every programmer worthy of the name should read. He just posted another essay that I would easily qualify as being of the same caliber, Making Wrong Code Look Wrong. I definitely consider this a must read, whether you agree with him or not. I am definitely one of those that never read Simonyi's essay that originated the notion of Hungarian notation. Spolky's explanation of the Apps dialect versus the Systems dialect makes a great deal of sense. I typically don't care for one or two letter fixtures in my variables, or even one or two character variables. Regardless, the intent, the guiding philosophy he's trying to impart just makes a lot of sense.

I think it is of a piece with the notion that high level programming languages (which is all of the but machine code, really), are for the benefit of the programmer, not the machine. Or not even the tools! I am surprised by how many programmers have a mechanistic rather than a considered or holistic view of what they do and just don't grok this notion, even if they can recite by rote.

Too often the resounding sentiment seems to run, "I must use ary for a list because that's best practices." Or whatever the superficial reasons they've swallowed for an otherwise arbitrary practice may be.

I actually interviewed one candidate, who when I asked him about a subtle difference between Java and C++, responded, "Why would you ask that? Isn't that more of a philosophical question?" He seemed floored that I would ask about the intention inherent in two languages approach to the same problem.

Absolutely there is a philosophy inherent in programming languages. And idioms and semantics. Because at the end of the day, they are really there to communicate with other people, not the machine.

I love Spolsky's article because, without saying it, he's talking about appropriate use of semantics. Not for mechanical purposes like typing or scope which can be better addressed by tools, like context sensitive or re-factoring IDE's and editors. If you make your really code spoke about your intent, what you were trying to make it do, it is that much easier to find, or even qualify, a potential bug.

Oh, and I'll give him a pass on the exception argument. Personally, I think they are like any tool and have an appropriate use and tend to think Joel's view is informed more by inappropriate use, read abuse, of the facility. But if you program with understanding and intent, well, you can make decision that I think any other such programmer won't have any trouble living with.