Beautiful Code
Had a conversation with Tony the other day about what beautiful code means and wanted to jot down some thoughts.
I think beautiful code has to do with three things:
- readability
- encapsulation/abstraction
- performance
As a beginner, the first is the most important to me. I’ve worked with code bases with poor naming, poor indentation, poor line-breaking practices, etc. And it makes it so much harder to read. There was a point in time when I believed that code must be hard to read (ahh, the good old days of PHP and Wordpress themes!), that’s why it’s code and not English. But in the end, programmers are just reading and writing another language. Good grammar, punctuation, and structure should be a norm. Random aside on this, I don’t know how this applies to Unix systems and terminal yet. Everything in there might as well be a random string of characters…
By encapsulation/abstraction I mean good, DRY code. I’m working with a rails app now that has 400 line views. As my boss says, “that is not ok.” It’s like writing a freehand essay where you’re not allowed to use the backspace or return buttons. It’s kind of like I’m writing this post right now. (If the previous sentence, and this one, are still here, it means I definitely did not refactor” or in any way revisit this post after writing.) The benefits of modularizing your code also contribute to readability in the end. If you don’t modularize, it’s so much easier to run into conflicting namespaces and random bugs, no matter how smart you are.
I’m not even a beginner on the last one. When I built Startapathy and posted it on HN, it got a decent amount of traffic. More than I had ever seen anyway. The app randomly didn’t work for some people and I naively figured/hoped I was having “scaling issues”. Not true in the slightest. The point of that story was that I have very little clue (yet)* of what “code that performs well” means. But I do know that an application is meant to make a task either possible, if it isn’t already, or more efficient, if it already is. For most, applications are trying to do the latter so it only makes sense that the more performant some software is, the more people will like it, and the more inherently beautiful it is.
*I know infinite loops are bad. An 8 year old who has to ask Mom and then Dad and then Mom and then Dad… if they can stay up another hour knows infinite loops are bad. I also know that querying databases too many times is bad and indexing the right things is good. Still not a big deal. I’m learning Ember.js right now (which basically bundles server calls by caching your data), so now I know reducing server calls is good (up for debate).
