This post originated from an RSS feed registered with Agile Buzz by Laurent Bossavit. Original Post: The "best" code Feed Title: Incipient(thoughts) Feed URL: http://bossavit.com/thoughts/index.rdf Feed Description: You're in a maze of twisty little decisions, all alike. You're in a maze of twisty little decisions, all different. Latest Agile Buzz Posts Latest Agile Buzz Posts by Laurent Bossavit Latest Posts From Incipient(thoughts)

Spurred by programmers' reactions to a refactoring exercise in a class he teaches, in which people seem to prefer leaving some duplication in the code because it appears to communicate intent better, Ron Jeffries asked:

What is the "best" code? Is it the code with minimal number of symbols or minimal number of statements or opcodes? Or is it the code that will communicate best with the reader?

This sort of problem crops up time and again in Douglas Hofstadter's book on translation, Le Ton Beau De Marot, and he makes a good case that it is a fundamental feature of what it is to express ideas.

When trying to translate an English term, say "breakfast", to French, you might hit on "déjeûner". This doesn't quite work, though, because as a noun you would say "le petit déjeûner". "Petit" means "little", we call the first meal of the day "small" because the midday meal is called "déjeûner", and we typically eat more.

"Breakfast" and "déjeûner" are almost literal translations of each other - the latter would literally translate as "un-fast". It's really too bad that you have to use two words to translate one, especially when the one word actually means, etymologically speaking, what you end up having to say with two. Argh !

Coding raises the same kind of uneasy tension between semantic issues and formal ones. This bit of code has meaning closer to what we want to say, except that it has duplication.

There's something like "grain size" involved in this. For instance, if you're translating the single word "breakfast" then you're stuck - you can't preserve both meaning and word count. But if you're translating a larger fragment, a sentence or a paragraph, it's much easier to get a translation that globally preserve word count (if for some reason you're trying to do that). There are ways to rearrange meaning around so that you end up in the right place.

I'm guessing that code is just like this, too - there are choices you need to make at a very small grain that leave no possibility of getting the "best" code in an absolute sense. "Best" is a point in abstract space but cannot be realized "physically" due to the grain size of code - a lot like drawing lines or circles at low-resolution, you can smooth out jaggies but not avoid them entirely, and at ultra- low resolutions the best algorithms will break down eventually.

Yet we can still recognize that abstract "best" and aim for getting ever closer to it in our imperfect realizations.