Image by Len Peralta for
Jonathan Coulton’s song “Code Monkey”

This post by Chad Fowler about 20 Rails development no-nos caught my eye, and not just because Fowler crowd-sourced it on Twitter. Fowler asked the question this way:

“what’s an example of one thing you find in other people’s Rails
code that you (almost) always consider to be wrong?”

That’s a great question, and he got interesting responses.

I found myself kind of drawn to the opposite questions — what would I find in somebody else’s code that would lead me to consider the code “great”. Working from the assumption that avoiding the no-no’s on Fowler’s list would make code good, is there something beyond the absence of bad ideas that makes code great?It turned out to be harder than I expected to tease out what I would consider greatness in code. In the end — well, it’s not really the end, but when it came time to actually write this post, I have what I think are three intertwined sets of characteristics of what great code looks like to me.

A lot of this is language independent — each individual language has it’s own little pools of quicksand to avoid, and Ruby is no exception, but at the level of greatness, I don’t think you can just say “using blocks makes Ruby code great” the way you can say “not using blocks makes Ruby code terrible”.

My working definition of great code, by the way, is code that makes me think, “I want to work with this person, because they know what they are doing”.

Emphasis on Readability

Nearly every feature or quirk that I think of as a sign of great code comes down to putting effort in toward making the code more readable.

Making code readable takes some effort, it’s an extra layer of polish during development for things like:

• Clear, meaningful variable and method names
• Consistent spacing and layout that matches the logical structure of the code
• Comments, where applicable, that describe rationale and intent and don’t reiterate what I can already determine from the code

Evidence of Refactoring

I’m not sure whether this is the same thing as readability — I think it’s more the same basic impulse directed in a slightly different way. The impulse is to take the time up front make the code as clean and clear as possible. Readability is aimed at the presentation of the code, refactoring is aimed and the structure of the code.

You can’t prove refactoring in an an application, but the TDD/Refactoring process leaves some clues:

• Short methods
• Relatively shallow nesting
• A lot of one line blocks (either in the Ruby or the language-independent sense) that call out to extracted methods
• A noticeable lack of duplication

Use of Language Tools

Great code uses the tools provided. In Ruby, that means blocks, monkey patching, and meta programming. A functional coding style works in Ruby, but doesn’t quite work in Java. I spent the better part of a year coding Java using Python-style idioms and my main achievement was irritating the rest of my team. In Rails, it’s knowing what extensions exist and not re-inventing them in your own code.

I’m just noodling about this right now, but I’m very interested in other thoughts about what you could see in code that convinces you of its greatness.

Share/Bookmark