- Language, Framework, and Runtime
- Speed
- Expressiveness
- Readability
- Summary
Readability
Sometimes you can write code that gets used for a bit and then thrown away. Most of the time, you aren’t so lucky. Eventually you have to go back and read it, or someone does. If you know you’re leaving the company soon, and you hate your coworkers, you might consider a language like Intercal or C++, with baroque syntax and even more peculiar semantics. On the other hand, if there’s a chance that you might be stuck maintaining the code, or you want to be able to show it to other people without hanging your head in shame, the readability of the language is important.
A lot of factors go into determining whether a language is readable. The most obvious is familiarity. The human mind is very good at adaptation, and often it’s astonishing what the mind will perceive as "normal." Familiarity only comes from constant exposure, though, which means that languages with relatively simple syntax become familiar more quickly. Lisp is at one extreme, with only one syntactic construct. It’s very easy to become familiar with Lisp, although grasping the large Common Lisp standard library is another matter. C++ is the popular language at the other extreme. Most C++ coders I have encountered use only a relatively small subset of the C++ language. Worse, everyone uses a slightly different subset, so C++ code written by other people may be quite difficult for you to read, even though you’re familiar with the language.
Another aspect of readability is the syntax itself. This is where Smalltalk-like languages tend to win. Since Objective-C allows the use of syntax that works for both C and Smalltalk, it’s a good language for an example. Apple provides a set of objects that are "toll-free bridged" between C and Objective-C. This means that a set of C functions are passed the Objective-C object as an opaque data type, so you can directly manipulate the Objective-C objects without having to translate them into some other form. This approach makes them ideal for a syntax comparison:
[array insertObject:anObject atIndex:12]; CFArrayInsertValueAtIndex(array, 12, anObject);
Both of these lines accomplish the same thing: inserting anObject into array at index 12. To understand this result from the first line above, you need to understand that the Objective-C message-passing syntax specified an object and then a list of parameter name:parameter pairs. To understand this result from the second example, you need to know how C function-calling works, that it’s conventional for the first argument in functions of this type to be the data structure being manipulated, and that the author of the function decided that the arguments for the function should be passed the opposite way to how they occur in the function name.
In this particular example, it’s quite easy to spot that 12 is the index, if you know that arrays are indexed by numbers. Now imagine that both arguments were variable names.
Of course, the biggest impact on readability comes not from the language, but from the developer. A poor developer can write illegible code in any language. A good developer? I’ve even seen well-written, readable Visual Basic code. (Once.)