Other Software > Developer's Corner

Beautiful Code: In your opinion, what makes code Beautiful?

(1/4) > >>

Codebyte:
Tonight a highly subjective question was proposed concerning "What Beautiful Code should be." There are a lot of important questions and while I understand this might be a very debatable topic, let's take some time to talk about this... Why? you might ask. Well, because it's important... Take a look at some of the following points made by our very own mouser, Gothi[c] and Deozaan:

1. It is better to have 20 lines of understandable clear simple code than 4 lines of complexity. - Mouser
2. The real question is does it make any non-negligable difference when it's all compiled down to bytecode anyway? If so, it probably needs to be evaluated for each programming language. - Deozaan
3. If it uses more memory, so what? Premature optimization is the root of all evil. Lets not optimize that until a problem is created by being too organized, which is near impossible. - CodeByter
4. Would you rather have a program use 100k extra memory or have the same program crash more often because its code is hard to understand? - mouser
5. If the program needs to read millions of pieces of data, then 1ms of delay can add up. - Deozaan
6. There's a balance between clear code and complex code with less lines. Just clarity at the cost of crazy insane slowdown would be silly. - Gothi[c]
7. Even when code is slower, you have to ask yourself, is it happening in a place that matters. There are very very few cases where it is better to have ugly short code than longer clearer code. - Mouser
8. We shouldn't strive to write longer code but rather to write code that is easy to understand. - Mouser
9. The goal should be: efficient easy to understand, short if possible, code. - Gothi[c]

In this discussion, Mouser mentions a list that I post on my site. Take a look at the list here: http://www.codebyter.com/2009/02/beautiful-code/

Now, you are completely briefed and ready to go. Post some thoughts you have concerning this highly debatable topic and keep in mind that no one is against you :)

mouser:
I'm not trying to knock the book beautiful code, but commenting on that list by codebyter from the book, i thought it conveyed the wrong focus.  It's focused much too much on brevity, and much too little on explanatory power.

One should not write source code like one writes poetry and literature.  One should write source code as if writing a textbook -- focusing on explanatory power and clarity.

I guess i can sum up my view like this:

* One should endeavor to write code which is most of all: clear and easy to read and understand.
* I think one is almost always better spending 20 lines writing something in a way that is crystal clear, than accomplishing the same thing in 2 lines of code that requires careful study.  The more "clever" those 2 lines of code are, the worse.
* Writing code is different from poetry and literature in that the goal should not be cleverness and coming up with some surprising and unusually short snippet of code that accomplishes something.
* Even in those very rare rare cases where the longer, clearer code uses more memory or takes more cpu cycles, and in which that speed/cpu difference actually impacts usability (truly rare cases), i still believe it's best to write it the clear way first, then come back and refactor later for efficiency if you must.
Or you might even be able to sum it up by saying:
Write code as if you're goal was to produce something that was self-explanatory, that could teach a new maintainer how the system works and make it as easy as possible for them to take over from you.  And note that the primary motivation for doing this is *not* because you might have to turn over control of the code at some point, but that this approach makes it easier for *you* to maintain the code going forward and makes it easier for you to debug, which is what you're going to be spending most of your time doing whether you like it or not.

zridling:
As a non-coder, my end sees good code stemming from good design. It's easy to over-design. To start out by saying, "Hmm, maybe somebody would find this useful, that useful, and also that, that, and that over there" will lead to future frustration. Start from what you know people must have, and then try to make that set smaller. When you can make it no smaller, you've reached a nice [starting] place with your project.

Oh, and that whole 'efficiency' thing mouser mentions is probably goes pretty far toward beautiful code, too.  ;)

Deozaan:
I agree with mouser. And I think it especially applies to beginners to programming. As you're learning how to program (or a specific language) it's best to be clear so you can understand what it is you're doing when you come back from a week vacation than to try to be clever at the moment and have to spend 15 minutes trying to figure out how a relatively simple function works.

In my own programming projects, I've found that I tend to try to be lazy or clever and I'm almost always successful if I spend enough time thinking about it. But then when I come back to it later I have to spend just as much time figuring out how it really works, even if I've commented it in a way I thought was clear at the time.

Also, I've often found myself spending hours trying to think of a clever way to accomplish something and then in the end I use the idea I had at the very beginning but decided it was too much work and there had to be a more clever simpler way. And usually in these situations I find that what I thought was the "harder" way is actually completed and working much sooner than those hours I spent coming up with and testing new tricks to accomplish the task.

Finally, I'll just point out that your Beautiful Code blog entry seems to be making the assumption that simple code is equal to less code is equal to shorter code. I think that the original idea is perverted along the lines from Simple to Short, much like a game of Telephonew. The original idea is "Simple code is beautiful code" and my interpretation of that is that simpler code is doing less things per line, resulting in shorter commands, but longer code.

Have you ever tried to understand source code you've never worked on? It can be very overwhelming. Code you can understand is indeed beautiful.

So if you simplify your code you will likely end up with more lines of code, but who doesn't like to brag about how many thousands of lines their code is? It makes a nice bullet point to show off how awesome your program is. Now, as with most things, there should be moderation. You shouldn't be a total zealot for only one simple thing per line of code always and forever. There is definitely a balance. The idea is to write your code simply and beautifully without going to extremes.

app103:
A program is just like a recipe...

If it's cryptic the cook (coder) won't understand it and the meal will come out a disaster at some point in time.

Say "peas" when you mean "peas", "carrots" when you mean "carrots", and "eggs" when you mean "eggs". (use good variable names)
Substituting with x, y, and z will not do. How does it make any sense to refer to an "egg" in a recipe as "z"?

It is usually better to break it down into step by step instructions instead of having one giant mega do-it-all-in-one-step (this agrees with mouser)

Plan for getting amnesia (you will) by leaving notes to yourself (comments) to explain why you used what you used, and did what you did. If something doesn't work and you have fixed it, leave a note to yourself not to try that again. Example in recipe talk: soy milk makes instant pudding runny, use real milk only.

The end result is a recipe (program) that you will be able to undersatand like a master chef (master coder).

And if/when the time comes that you have to pass the recipe (code) down to the next generation (coder), they will be able to understand it too.

Now, if what I said doesn't make sense, ask your grandmother to explain it. She is probably a much better hacker than you give her credit for.  ;)

Navigation

[0] Message Index

[#] Next page