Programming With Style

So, when I switch from one programming language to another do I change my coding style to fit the language? The answer is: up to a point. Or, to put it another way: as little as possible.

Obviously, a language such as Ruby is syntactically very different from a language such as C#. To take a couple of simple examples: Ruby does not require typed variable definitions, C# does; Ruby uses keyword..end pairs to delimit many language constructs whereas C# uses curly braces, and so on.

But beyond that, what about the specific ‘idioms’ applicable to specific languages? I came across this (largely negative) review of my Ruby programming book recently, which reminded me of just how fiercely devoted to language-specific idioms some programmers are. The truth of the matter is, I am not. I don’t make a habit of setting different tab-settings when I switch from one language to another (4 spaces per tab in C#, say, but 2 in Ruby) nor do I change my naming conventions for methods and variables any more than is absolutely required by the syntax of the language.

I have to say that, for purely aesthetic reasons, I have never liked excessive use of underscores in my method names but I have no objection if other people use them. Here is a passage from the introduction to The Book Of Ruby that explains my approach:

Matters of Ruby Style

Some Ruby programmers have very fixed—or even obsessive—views on what constitutes a “Ruby style” of programming. Some, for example, are passionately wedded to the idea that method_names_use_underscores while variableNamesDoNot. The style of naming in which separate words are indicated by capital letters likeThis is called camel case—and that is the last time it will be mentioned in this book.

I have never understood why people get so worked up about naming conventions. You like underscores, I can’t stand them; you say po_ta_toes, I say poTaToes. As far as I am concerned, the way in which you choose to write the names of identifiers in Ruby is of no interest to anyone but you or your programming colleagues. That is not to say that I have no opinions on programming style. On the contrary, I have very strong opinions. In my view, good programming style has nothing to do with naming conventions and everything to do with good code structure and clarity.

Language elements such as parentheses, for instance, are important. Parentheses clarify code and avoid ambiguity that, in a highly dynamic language such as Ruby, can mean the difference between a program that works as you expect and one that is full of surprises (also known as bugs). For more on this, refer to the index entries on “ambiguity” and “parentheses.”

In more than two decades of programming, one thing I have learned through bitter experience is that the most important characteristics of well written code are clarity and lack of ambiguity. Code that is easy to understand and easy to debug is also likely to be easier to maintain. If adopting certain naming conventions helps you achieve that goal, that’s fine. If not, that’s fine too. The Book of Ruby does not preach on matters of style.

Quite often, over the years, Ruby programmers have suggested that my stylistic preferences derive mainly from Java. That is simply not the case. For some insight into my stylistic preferences, however, you may want to take a look at a series of articles I wrote called Ruby The Smalltalk Way. I would also recommend the book ‘Smalltalk With Style’ by Klimas, Skublics and Thomas. You can download a copy of this book from Stephane Ducasse’s excellent repository of free Smalltalk texts: http://stephane.ducasse.free.fr/FreeBooks.html. While I don’t slavishly follow the stylistic ideals outlined in that book, I think the fundamental ideas are sound.

Actually, I suppose I should own up to one pretty strong stylistic prejudice and it is this: if you want to develop a good object oriented programming style, learn Smalltalk!