Viridium.ro

Years ago, someone on Undernet’s #java was telling us that his Java methods followed an old C pattern: variable declarations at the top, code to initialize and use the variables down below. (Surprisingly similar to the var debate, isn’t it?) Is it good, or bad? Well, if variable names are cryptic enough that you can’t infer the type, then yes, it is bad. However…

Writing readable code involves the use of policies by developer that are currently beyond what can be enforced by compilers or IDEs today. In this context, should the language provide a keyword that has the potential to reduce the readability of the code? Well, it has, so what now?

I hate to have to say it, but the problem in many of the examples out there is not the use of var itself, but the lack of proper policies when writing code, the most notable of which is the use of descriptive variable names. I always use descriptive variable names and descriptive method names in my code. This policy should already be in place where you work, just like the policy requiring you to keep the size of your methods small.

The points made by some members of the blogosphere, criticizers of var’s use beyond its original purpose, become less and less pertinent as we look at each claim. Until the compiler learns to enforce the use of good variable names, I agree that there is much potential for writing cryptic code through the use of var, but that’s as far as people should go with the claims. The decision of whether to use var should be made on a case by case basis. My feeling is that, if you’re good enough of a coder to write elegant code, var won’t stop you from getting there. On the contrary, it may well help alot.

Var can alleviate some of the verbosity issues, which in turn impair readability, or it can destroy your code’s readability. In fact, if your code’s readability rests on the shoulders of the type declarations, then I’m already sorry for your code, my friend. The readability rests in the code’s elegance and simplicity, which includes good variable names.

Code closer to natural language has a better chance of being readable, and var can help that out. If you’re still not convinced, consider that JavaScript has always had this var thing running around, and that hasn’t prevented good coders from writing good, readable JavaScript.