Compound Thinking

Python, Ruby, Rails and Readability

When developing code you should always choose readability over convenience. Code will be read many, many more times than it is written…

–Practices of an Agile Developer by Venkat Subramaniam Andy Hunt

This quote from Ruby advocate and Rails book author Andy Hunt, explains why I work in Python even though Ruby has anonymous blocks and slightly less historical baggage than Python.

I recently taught a couple of free introductory classes, one for Python and another for Ruby. People with little experience in either language, could quickly read Python code. But with Ruby — and Rails in particular — there is so much heavy use of the “power features” of the language — like dynamic classes — that code readability was severely compromised. New programmers were quickly confused and lost. There were lots of “where does this happen” questions. Dave Heinemeier Hanson carries most of the blame here: Rails is built on his philosophy that values “convention always trumps configuration” and “less code is better” so highly that other critical considerations like the value of locality and orthogonality play in making code readable. In my view this is a serious mistake. After all, Code is read more often than it is written!

Wherever possible methods should be understandable on their own. No matter how powerful dynamic classes and objects are, using them means there will always becode elsewhere in your system that changes the behavior of the code you write — that means you have to know about and understand all of that elsewhere just to understand — and debug — the object in front of you.
For example, Rails has this nifty feature where Database classes map to table names that are the plural of the class name. This auto-pluralization like other Rails hacks is cute and fun at first, and it certainly makes the surface of the code shiny and pretty, but it also creates a layer of indirection and “magic” that obscures what is happening under the covers.

Of course, sometimes you have to make hard choices and it’s worth sacrificing code readability for other concerns. I’m not disputing that, I’m just saying the code you write — if it’s used and maintained — is going to be read many, many more times than it is written. So, you ought to optimize for the code reading experience, and more than any other language I’ve used, Python is designed just that.