Saturday, March 8, 2008

Trick Question: What's Your Programming Style?

I recently wrote a JavaScript thing I was handing off to other programmers with less experience. I used new Array() instead of [], and wrote relatively verbose comments..

Now I'm working on a personal project in Ruby, exploring algorithmic composition and Lisp-style programming techniques.

I used that double-brackets notation elsewhere, in my comments on a blog post where I wanted to challenge the blog's author to more elegant "metaprogramming."

I know it's hard to understand. That's the point.

The JavaScript code is almost over-commented; the Ruby code heads in the direction of obfuscated Perl. Less experienced programmers need to be able to understand my JavaScript, and adapt it. The Ruby code uses so many advanced (or maybe just uncommon) techniques that accomodating less-experienced programmers is impossible either way you slice it, and while I wanted the JavaScript to be easy to understand, I had different goals for the Ruby. I created some of it strictly for my own use, some of it to challenge myself, and the rest of it to challenge somebody else.

Having only one programming style is like knowing only one language.

If you live in a small town, if you're always at home, if you only ever eat a certain kind of food, then it makes sense to have one favorite restaurant, but if you go out a lot and you know a lot of people, you're going to have a favorite sushi place, a favorite taco stand, a favorite cafe, etc. Here in Los Angeles, I have a favorite cafe in Hollywood, a favorite cafe in West LA, a favorite cafe downtown, a favorite cafe in Silverlake, and a second favorite cafe in Silverlake. I don't even leave the house that much, but wherever I am, I've usually got my laptop with me, and it's usually useful for me to stop and get a cappuccino, so it makes sense that I know more than one cafe.

Likewise, it makes sense to know more than one programming language, because different languages suit different contexts, and it makes sense to have more than one programming style, for the same reason. The style you use when you want to stretch your skills, or challenge someone else to do the same, should be a different style than the style you use to make life easy for newbies (or yourself). A lot of people say you should favor simple clarity over succinct power, or vice versa. The truth is you should prioritize whichever one serves you best in a given situation.