Perl and Python share one particular idiosyncrasy I dislike, the habit of naming_stuff_with_underscore.
There was a time when I mocked naming variables, methods and functions in a verbose way. I had just learnt C and anything longer than atoi seemed wasteful of precious, uhm, something. I was sure someone would die if anything longer turned up. It’s true, overly long names can sometimes make code very difficult to read, and often used things should probably use short names. However UIAlertView is a helluva lot clearer than UIav, and drinkBeer is a lot easier to swallow than a plain, short db, especially after calling it a few times. 9 times out of 10 abbreviating things or using cryptic names will only make it more difficult for anyone planning to maintain the code.
So what does this have to do with how variables should be named? Simple, really. It’s to do with our brain. If we have now agreed that verbose names are good, we know look at how those verbose names look like. As anyone who has coded until the early hours will know, humans are really quite bad at parsing stuff a compiler does with ease. Otherwise we’d never miss that missing semi-colon. So, going back to beer, here is one example:
beer_crate.guinness_can.drink(gulp_factory.create_gulps(3))
Sure, this particular object model feels a bit Javaish, but it’s not uncommon to see code like this, and obviously I’m trying to emphasise the point. Not only do the underscores visually separate terms which are actually the closest to one another conceptually, they can get mixed up with the dots, especially with monospace fonts. I don’t mean it’s impossible to read, but it’s not as easy as it could be, and with heaps of code staring at you, anything helps. Just try to imagine pages full of that.
This really dates back to when there were just functions and none of this OO nonsense . drink_guinness() is not particularly unclear in comparison. However, as OO rocks for other reasons, we have to live with structured calls. For comparison I’ll use the common syntax of a couple of other languages:
beerCrate.guinnessCan.drink(GulpFactory.createGulps(3));
[beerCrate guinnessCan] drink [GulpFactory createGulps 3]
[[beerCrate getGuinnessCan] drink: [GulpFactory createGulps: 3]];
Take your pick, but any of those are clearer, despite messing around with a silly factory class. Our brains are wired to separate space and thus they are very effective at parsing those into chunks of related information, without underscores to confuse the parsing. Not only that, but they’re quicker to type too (if only marginally).
Almost every popular language out there has widely adopted the camelCase format, at least for public APIs and libraries. And quite a few less popular languages have too. There are good reasons for why this is good.
The really ridiculous thing with Python is they have been unable to decide what they want. Classes are named properly, variables and methods are not. In fact, there’s loads of Python code that proves my point about brain parsing. It’s not uncommon to see something like: beercreate.guinnesscan.drink(). Yes, that is easy for the brain to parse into chunks as well (possibly even easier than camel case), but it’s bringing in another problem: word separation. A separate issue, but not one to ignore either.
Python goes as far as to have this underscore style presented as ‘standard’, so any glimpse of originality will be immediately squashed with a “but it’s not policy”. And no I didn’t read the PEP. After all, I know I’m right.