A virtue in writing code is clarity, or writing code that is easily read; that communicates its intent. This goes with choosing good names for variables, methods, and objects. In this context, Hungarian Notation is sometimes dismissed by some as being absolutely contrary to this virtue. How can mpcopx possibly convey anything to anyone?

But what is wrong with having a system for naming which allows for saying much in a short string of characters, provided that the programmers who work with the code is familiar with the notation? Hungarian Notation seems to be dismissed because the names can’t be understood up front: You need to learn the notation, as well as the types used locally – otherwise, you’ll never know what a rgbsyHash is.

Now, I’m all for spelling names out, and thus not a fan of Hungarian Notation, but I see the benefits of having such a notation. Having a special system that is familiar to the team members can help in writing clear code. After all, this occurs in any project, as there is always a flavor to the naming standard.

For some reason, I began reading Mark Pilgrim’s Dive Into Python yesterday, and I came to think about this as I first read the code example at the beginning of the chapter The Power of Introspection. I couldn’t understand the first two lines – especially not the second one (the one starting with “processFunc = […]”). But Mark explains each little part of that function, so that by the end of the chapter, the code example is no mystery at all. In fact, understanding lambda functions, list comprehensions, etc, enables you to write code that is both brief and clear – to people that also are familiar with this.

So this is something that’s present in all programming languages, although some are arguably easier to understand without prior knowledge than others – such as Smalltalk versus Perl. But I remember having a hard time understanding blocks in Smalltalk, which is a good example of something that can be very powerful, albeit not as obvious as the rest of the language.