I’ve been holding off on getting into a semi-religious debate about code style, but I might as well give my $.02 at this point.

You say, “Code needs to be easily human readable”, which I absolutely agree with. However, this does not always mean “variable names totally need to have meaning”.

When I grade code on it’s readability, variable naming is actually at the very bottom of my list of things to care about, which looks like this:

An overview comment that provides describes what the file/class/module does at a high level, what requirements it has, and that gives an example of how the API is used.
Public Method and Var docs that describe method behavior, and inputs/outputs, and what generally what state is accessible through the API
Inline comments that provide a pseudo-code level description of what the code is doing.
Descriptive variable names

I put far more weight on #1 and #2 than I do on #3 and #4. As long as there are good doc-comments that accurately describe the public API, I’m not going to get too bent out of shape about the rest. The only time #3 and #4 are important are when you have to dive into the code implementation to figure out what exactly is happening. If the developer has done a good job with the first two, that shouldn’t be necessary (too often… for stable code… that doesn’t have bugs… that you don’t need to port or adapt. Hmm, okay, maybe it’s sorta important. )

Where variable names are concerned specifically, the problem is that sometimes there simply isn’t a good descriptive name. This is particularly true in abstract problem spaces like cryptography and, surprise, geometry and math. You often have variables that hold interim state for which there simply is no good description. Check out the pseudo-code for the MD5 algorithm for an example. I’m pretty sure this is what we’re seeing in the JS graphics file.

Obviously this is less often the case with variables that appear as part of a public API. Those variables are more likely to have a concise semantic meaning and their name should reflect that, of course. But when it comes to what’s inside the “{…}”s of a method, insisting on descriptive names can actually be counter-productive. You’ll end up with real head-scratchers like, “rotatingHashAccumulator3″, which aren’t actually any more readable, and just blow out what should be a single line of code across a half-dozen lines (making things less readable, not more so!)

This is why I personally emphasize inline comments over variable names. They are much more effective at making code readable, and they give you more latitude to use names that suit your coding style, whatever that may be. They can also be a useful productivity tool – I’ll often write these comments first to “plan” what my implementation is going to be, and then fill in the source code.

So there you have it. In the case of the JS graphics file, it has good introductory comments, but it lacks the method-level documentation that I think pretty much all public libraries should have. It would also benefit from inline comments that explain the various algorithmic behavior, something longer variable names probably wouldn’t do much for.

(P.S. Short var names don’t have a significant impact on code size when JS files are gzip’ed. And if yo’re not gzip’ing, you’ve got bigger problems than var names.)

When in development, variable names totally need to have meaning. There’s no way around this – you develop code with short vars, 6 months later you don’t know if ‘rw’ means ‘right wing’ or ‘right window’. Code needs to be easily human readable.

Now, compressing code on a production server is a best practice, and a very important one, but that’s what things like Dean Edwards’ Packer is for, or the Asset Packages I blogged about before.

That’s why you’ll notice many of the popular open source libraries (like jQuery) have different compressions of the code you can download, depending on your purposes. That’s open-source that rocks it.

1) My tumblr blog should not be taken seriously.

2) I wasn’t bashing the idea of open source code or even directly criticizing that jQuery plugin in particular (kind of surprised you figured out the plugin from the short code screenshot I posted). I was criticizing bad programming style, and I think I have every right to.

I never program anything without doing everything I can to help maintainability. There is a style to code and it should be open to critique – nobody should program with one letter variables because it’s bad practice. (just ask wikipedia) It’s the same as saying nobody should design a professional site with Comic Sans, or drive on the wrong side of the highway. Standards help everyone think on the same page, and having meaningful variables is one of the strongest programming conventions in existence. Things like whitespace can be overlooked – variable names really can’t be.

To answer your first point, the Canvas class I’ve been writing has been started from scratch, and it’s been a solid 2 months of crazy changing evolution as I scale up the functionality. I’m sure I could have wrote things better, I’m far from being the best programmer in the universe. However, I do maintain proper style in my code, and I do take pride in that.

I’m not implying that the jQuery plugin code is ‘broken’ and that it should be fixed. Sure, I can go in there and decypher the variable names to give them meaning and return the code to them, but – why? I just took a look at the code to see how other people were using Canvas. The only reason I ranted was because of the programming practice, not that I hated the actual plugin.

The copyright notices in the code in question show exactly how it’s audience changed unexpectedly. It’s a jQuery port done by one person, of code that was written by someone else years before jQuery was created. How big an audience was there _really_ for a JavaScript fillEllipse function back in 2000-2004? This is the beauty of opensource: it allows something that was probably a small weekend experiment by someone years ago to become an important part of a high-profile project today.

I would be remiss to not point out that these two cases are fundamentally different in a different respect. Startups often go to great lengths to attract and entice users, which invites a certain justifiable expectation of support and performance on the users’ part. Startups also benefit tremendously from said users adopting their service and coming to rely on it. (This is, after all, often what determines whether a startup succeeds or fails). In contrast, vast majority of opensource developers act out of simple altruism, a desire to help other developers avoid wasting time reproducing their efforts, with little in the way of compensation or reward.

“Here’s what I’ve done so far. ‘Hope you find it useful.”

Here are a few questions to ponder:

- How long would it have taken you to write that graphics library from scratch? Given the demands on your time, could you have done any better?

- Who should fix the problems you’re criticizing? You have access to the code repository after a; by not fixing it yourself, are you implicitly saying your time is worth more than the code author’s?

I defend startups because the problems that tend to happen with them aren’t really predictable or controllable by the people who create them. Mark Zuckerberg started Facebook for his college friends – now it has over 150 million *active* users. Even the best teams can only scale their app so fast, and the expectation of people to have a service at their disposal whenever and however they want is a bit too high. Without wanting to oversimplify, web services are a privilege, not a right (unless you’re a paying member).

The reason I get openly frustrated with bad programming habits is because they’re completely under the control of the developer. I would never release a piece of open source code without making every possible attempt to make sure the people who adopt it can understand how it works. Code is art, how you craft it is very important, and when someone doesn’t take the care and effort to do so it comes off as lazy. I can’t stand lazy, it’s a huge pet peeve of mine.

Hopefully that’ll satisfy the hypocrisy police.

One could argue that the relationship between a startup and their users is much the same as that between a person who writes a piece of [opensource] code and the developers who benefit from it.

*ahem*

That stomping noise you hear is, I believe, the sound of the Hypocracy Cops, in their metal-toed boots, beating a path to your door.