It happens time and time again on mailing lists and
discussion forums – someone posts some code in the context of an example and
then there is an outcry. “The code is
lousy!”, someone says. So you look and you realize that “lousy”, to this
person, means that that it doesn’t use language feature X, that just came out
in the last release; or that its author didn’t use idiom Y, which someone
in some recent article proved is necessary to write “good” code in a particular
language.
Sound familiar? It happens all the time.
The truth is, I was one of those guys. Years ago, I took a lot of pride in the fact
that I was knew all of the nooks and crannies of C++. I nearly memorized the ARM (Annotated C++ Reference Manual), and in
flamewars on the net, I did my language-lawyerly best to point out little
problems in posted code, and (I thought) advance the state of practice a bit. But, I always felt odd about it. If writing code one way was okay before the
introduction of a new language feature, what made it bad immediately afterward?
Java and C# offer some great examples. If you are working in Java 5 or 6, you must use varargs when you can. If you’re working in C# 2.0, well, you must make a class static if all of its members are static. It’s just the right thing to do. Then, of course, there’s the issue of generics. Before their introduction, people would cast objects as they retrieved them from containers. Afterward, “good practice” dictated that you use type-safe collections and avoid the casts. It was just seen as “the right thing to do.” But, of course, if you work in JavaScript, Python, or Ruby, you can play by different rules because these "rightness" rules vary across languages.
It’s hard to fault anyone for trying to keep up with
language developments. If there are, now,
safer and better ways of writing code, isn’t it important to move along? I think it is, but only to a point.
The fact of the matter is, there is a strong psychological component to language expertise. The people who become language lawyers (and I was one of them) aren’t doing anything complex, they are actually doing something very simple. They are sitting down and learning all of the rules and using them as a point of leverage. They think, "I am valuable if I know the right way to use the language." But, frankly, there is harder work out there.
If you want to see that harder work, try to give advice to
people who are working in less than current environments. Try to write libraries and tools for people
who are working in antiquated environments. That is the point where you see the continuum. You can write good code without the
latest features. People do it
all the time.
There isn't some continually moving standard for good practice in a language, there are hundreds of islands, places where people have discovered what works for them in their environment. Sure, there are incremental advantages to using the new bells and whistles but they aren't going to make you or break you.
Language expertise is fine, but it isn’t the most valuable thing out there. If someone programs conscientiously, I can work with them. I have a lot of respect for people who write solid code despite not having completely up to date language knowledge. Language knowledge is easy: you read, you think, you try. And, you can catch up. Conscientiousness, though, is the thing that really matters. Next to it, language expertise is easy.
