“Beauty is bought by judgement of the eye”.

That said, I think most programmers will agree that beautiful code demonstrates a balance between clarity and transparency, elegance, efficiency and aesthetics.

• Clarity and Transparency: Clarity is how easily a reader can deduce what the code does. Transparent code does what it seems to do. If code seems to do one thing but actually does something else (or something more), it’s not transparent – it’s misleading.

• Elegance: there are many ways to implement most algorithms, but some ways are clumsy while other ways are neat and graceful. Succinctness often adds elegance, but excessive succinctness can reduce clarity.

• Efficiency: avoiding unnecessary use of resources (such as CPU time, memory, and I/O).

• Aesthetics: being easy on the eyes. This is quite subjective. It mostly comes down to style. One important consideration is to have a consistent style. Code which changes, for example, indenting style halfway through, is ugly.

Don’t let people fool you into thinking that beautiful code is the following:

• clever algorithms
• sneaky language features
• solving a problem with the least amount of key strokes

Because it’s not. Code like that is cute, and it’s certainly worth a glance, but it’s not the kind of code you want to settle down with.

And you know that fancy recursive meta templated static polymorphism that inherits variatic lambdas– or whatever it was you read about online? You might be eager to jump on innovative and nifty tricks without a clear reason to use them.
But code that pushes the boundaries of a language aren’t beautiful either.

They’re sexy.
Tons of fun, but ask yourself this: Do I really want to spend time exploring the anatomy of this language, or do I want to work together with a language and build something beautiful? After all, a programming language is merely the tool to create.

So what is beautiful code then?

Beautiful code = maintainable code. THAT’S IT!
THAT’S THE FORMULA!

If you can write something, come back to it a few months later, and continue making progress on it, then that’s beautiful. If a year later you realize that you want to add functionality as well as tweak an existing feature, and you manage to do it with relative ease, then THAT’S beautiful. If other people can step into your codebase and quickly figure out what’s going on because things are organized, they’ll have more hair, and also be beautiful.

So the real question you want to ask is: “How do I write more maintainable code?”.
I’m afraid that’s a bigger question and it’s quite a creative discipline. Just keep writing code, but this time don’t ask yourself if it can be more beautiful. Ask yourself if you can make it more maintainable.

My take on this is that “Beautiful Code” is not an objective or particularly useful term. And we should not try to define it.

Typical dictionary definitions of the English word “beauty” go like this:

• “1. the combination of all the qualities of a person or thing that delight the senses and please the mind”
• “1. the quality present in a person or thing that gives intense aesthetic pleasure or deep satisfaction to the mind or the senses.”
• “1. The quality that gives pleasure to the mind or senses and is associated with such properties as harmony of form or color, excellence of artistry, truthfulness, and originality.”

(Source http://dictionary.com)

The common thread is that “beauty” is about what is aesthetically pleasing. That is necessarily subjective … as illustrated by the saying “Beauty is in the eye of the beholder”.

We can apply the word “beauty” to code, and the obvious meaning is that the code is “aesthetically pleasing”.

But to then say that “beautiful code” has a certain set of attributes (as suggested by other Answers) is a contradiction of the obvious meaning of aesthetically pleasing. Aesthetics is about how people … individual people … perceive things.

Or to put it another way, there is something repugnant about someone telling me what I should think is beautiful, be it in people, works of art, or … code.

As far as I am concerned beautiful code is code that I think is beautiful, and that is it. It is subjective and individual, and lets just leave it at that.

Here is my advice.

Look through the answers to How can you explain “beautiful code” to a non-programmer? and see what characteristics they say to focus on. Then pick up a book like Code Complete and read it through to learn advice on how to write better code.

At some point it will hit you while looking at older code of yours, “This is ugly.” It will be a direct aesthetic reaction. And looking at it you’ll realize that you’re viewing your code like a programmer, and can see the ugliness because you know what better looking code should look like.

Just because you often read about beautiful code doesn’t mean people who write about it have the same definition. Sadly, judging by your question it doesn’t seem that they even bothered to define it in the first place.

To me beautiful code is :

• Expressive
• Concise

Concise code that is not expressive can be cryptic, and expressive code that is not concise tends to be bloated and tedious to read, so you need both.

I wouldn’t include maintainability as part of what makes code beautiful, because beauty is something you see/read, not something you act upon. But then again it’s my personal view.

The term beautiful code is a very vague and abstract term.
Its easy to figure out what it represents, and what it means, but it should never be seen as more than a secondary goal.

It reminds me a lot of the code coverage metric. When you get the number high enough you can relax and go onto something else. Having a codebase with about 80% coverage is great, not bulletproof, but enough to chill and do other things. Having 40% coverage is pretty scary and should encourage you to get that number up.

Point is just that code coverage is only really meaningful if the number is low. So don’t let it be low. When the coverage rises to a certain point, move on to something else.

Similarly beautiful code is great. If you have pretty code, great, move on to something else. Don’t stress too much about it. You’ll never ever hit that 100% mark, and if you do you’ll find you’ve focused too much on what it reads like, or what it looks like, and not enough on what it does, or how it does it. So get to a reasonable mark and then stop.

But if your code is fugly, if its a giant convoluted mess of spaghetti code, if it physically pains you to open the file, if you have no comments or documentation etc etc etc then fix it. And do it asap.

You’ll find over time your code base ends up generally cleaner, generally brighter and generally more beautiful and more importantly more usable when you focus on making it less fugly. Writing beautiful code is not a one step process.

There is no magic philosophy. Its 1000 smaller steps all done together, all of which serve a concrete purpose that has nothing to do with how beautiful the code looks. But, when you serve them up all together, they form beautiful code as the sum of its parts. Like voltron. Or captain planet.

I agree with the answers here really, but taking a less technical approach I would say beautiful code is an expression of its authors’ clarity of thought of the problem at hand which manifests itself through a well-formulated and precise yet simple language.

For me, looking through beautiful code is much like looking at a piece of art, seeing ever new details that show the maker’s intention, but also how the different parts were realised, each giving an answer to so many questions, and then, finally, how its existence feels like a natural law to which everything aligns such that it can only be described with words of awe: magnificient, inspiring, beautiful.

So from that perspective, in your career as a programmer you might make discoveries of beautiful code others might neither understand because they lack the knowledge or might not find noteworthy anymore as they have been spoiled by too much beauty 😉

Beautiful code has all the pragmatic qualities as mentioned otherwise, I totally agree.

I have three criteria:

• Simple: At least it must be human readable. For example, you can write a code that works at O(1) for a solution with tons of lines, but I prefer code that works with 0(n) solves with few lines. This might change for extreme situations but for the beginning simplicity is important.
• Reusable: Code must be reusable, but not overwritten. If you need an operation, you should define it the way that you can use it years later.
• Indentation: Maybe this is not a problem for you, but for the beginner-level, this is first thing to be solved.