In this question I asked whether being a bad writer hinders you from writing good code. Many of the answers started of with "it depends on what you mean by good code".

It appears that the term "good code" and "bad code" are very subjective. Since I have one view, it may be very different from others' view of them.

So what does it mean to write "good code"? What is "good code"?


13 Answers 13


A good coder is like a good pool player.

When you see a professional pool player, you at first might not be impressed: "Sure, they got all of the balls in, but they had only easy shots!" This is because, when a pool player is making her shot, she doesn't think about what ball will go into which pocket, she's also thinking about where the cue ball will end up. Setting up for the next shot takes tremendous skill and practice, but it also means that it looks easy.

Now, bringing this metaphor to code, a good coder writes code that looks like it was easy and straightforward to do. Many of the examples by Brian Kernighan in his books follow this pattern. Part of the "trick" is coming up with a proper conceptualization of the problem and its solution. When we don't understand a problem well enough, we're more likely to over-complicate our solutions, and we will fail to see unifying ideas.

With a proper conceptualization of the problem, you get everything else: readability, maintainability, efficiency, and correctness. Because the solution seems so straightforward, there will likely be fewer comments, because extra explanation is unnecessary. A good coder can also see the long term vision of the product, and form their conceptualizations accordingly.

  • 10
    "a good coder writes code that looks like it was easy and straightforward to do." << EXACTLY! I think this is because people usually think a good coder is someone who can write very "clever" hacks. If the code is clean and not overly "clever", it must be easy, right?
    – hasen
    Nov 7, 2010 at 23:19
  • 3
    My 2 cents: when you've got a language with EASY automatic refactorings -- Java and C# are the two examples I know best -- it's easy to move to good code iteratively. Otherwise you have to conceptualize well in the first place, but there is a sort of chicken-egg problem there. Nov 7, 2010 at 23:51
  • 3
    Some algorithms are intrinsically complex. A good coder should have no problem writing them when they are really needed -- and keeping them as readable as possible.
    – J-16 SDiZ
    Nov 8, 2010 at 4:15
  • 2
    @hasenj : yes, this is because of this lemma : stupid people write code the compiler understands. Clever people write code stupid people understands.
    – v.oddou
    Oct 23, 2014 at 3:43

WTF's per minute


EDIT: The basic idea is that "Code Quality" cannot be put into rules, in the same way that you cannot put "Good art" or "Good poetry" into rules so you can let a computer determine say "Yes, good art" or "No, bad poetry". Currently the only way is to see how easily understandable the code is to other humans.

  • 2
    Aside from being a great cartoon I think it really gets to the point - good code is code that other people find pleasant to read and maintain.
    – FinnNk
    Nov 7, 2010 at 14:40
  • 1
    So true, good code is any code that is not bad. E.g its hard to define good code, it is easier to define bad code.
    – Ernelli
    Nov 7, 2010 at 17:43
  • 5
    Usually I find those "WTF?"'s in the good code meeting are shortly followed up by "Oooooh Okay... I see what you did thar."
    – AndrewKS
    Nov 8, 2010 at 17:49

There is really no good criteria other than how fast you can understand the code. You make your code look good by finding the perfect compromise between succinctness and readability.

The "WTF's per minute" (above) is true but it's just a corollary of the more general rule. The more WTFs the slower the understanding.

  • 1
    @rmx: define "doing the job well"
    – mojuba
    Nov 7, 2010 at 11:20
  • 2
    Well, that the RemoveCustomer method actually removes the cutomer without screwing up. You can spend hours making it look pretty, but that doesnt mean it actually works. 'How fast you can understand code' is not the only criteria for 'good code' is what I'm saying.
    – Nobody
    Nov 7, 2010 at 11:27
  • 2
    @rmx: but being bug free is implied, isn't it? If your code doesn't do the job properly, it's not code (yet).
    – mojuba
    Nov 7, 2010 at 11:31
  • 4
    @rmx: in fact, no. If your code is easy to understand, then in conclusion it's easy to understand if it does it's job badly. OTOH, if it's hard to understand, it's hard to understand if it does it's job at all. Nov 7, 2010 at 11:34
  • 2
    @rmx: P.S. put simply, your decrement() is a classical WTF and thus it slows down understanding of parts of code where this function is used
    – mojuba
    Nov 7, 2010 at 12:15

You know you write good code when...

  1. The customer is happy
  2. Fellow coworkers borrow your code as a starting point
  3. The brand new guy/gal was just told to make modifications to a system you built 6 months ago and he/she never once asked you a question
  4. Your boss asks you to develop new widgets for the team to use
  5. You look at the code you write today and say to yourself "I wish I had written code like this two years ago"

How do you measure whether the code is good...

  • What is the response time?
  • How many round trips to the server does it make?
  • Would you personally use the application or do you thinks it's clunky?
  • Would you build it the same way next time?

Good code works when it's supposed to. Good code can easily be modified when it needs to. Good code can be reused to make a profit.


A code which is

  1. bug free

  2. reusable

  3. independent

  4. less complex

  5. well documented

  6. easy to chage

is called good code.

A good program works flawlessly and has no bugs. But what internal qualities produce such perfection?. It's no mystery, we just need some occasional reminding. Whether you code in C/C++, C#, Java, Basic, Perl, COBOL, or ASM, all good programming exhibits the same time-honored qualities: simplicity, readability, modularity, layering, design, efficiency, elegance, and clarityefficiency, elegance, and clarity

Source : MSDN

  • Simplicity, readability, elegance and clarity are all same thing. Modularity and layering are just methods of making your code clear and elegant. The only thing left in the list then is efficiency, which is kind of implied, and besides it is often a matter of compromising between efficiency and clarity.
    – mojuba
    Nov 7, 2010 at 11:48
  • Check this : goo.gl/hdQt8 Nov 7, 2010 at 12:19
  • 2
    Code can be bug free? Aug 2, 2011 at 16:41
  • No it can't. (Practically) Aug 3, 2011 at 16:57
  • Efficient should be added to your list. Speed isn't necessarily a primary indicator of good code, but good code shouldn't be unnecessarily slow or wasteful.
    – Caleb
    Apr 16, 2012 at 3:09

Does this seem familiar?

Philips gave me the opportunity to watch the design of a new product. As it developed, I became increasingly uneasy and started to confide my concerns to my supervisor. I repeatedly told him that the designs were not “clean” and that they should be “beautiful” in the way that Dijkstra’s designs were beautiful. He did not find this to be a useful comment. He reminded me that we were engineers, not artists. In his mind I was simply expressing my taste and he wanted to know what criterion I was using in making my judgement. I was unable to tell him! Because I could not explain what principles were being violated, my comments were simply ignored and the work went on. Sensing that there must be a way to explain and provide motivation for my “taste”, I began to try to find a principle that would distinguish good designs from bad ones. Engineers are very pragmatic; they may admire beauty, but they seek utility. I tried to find an explanation of why “beauty” was useful.

Please see the rest here.

  • 1
    Since the link in @mlvljr's post is broken, here is a link to the Google Books page: books.google.co.in/…
    – balajeerc
    Mar 28, 2015 at 9:10
  • @balajeerc Thanks (I also fixed the link, so it points to a Springer-hosted version of the same pdf) :)
    – mlvljr
    Mar 29, 2015 at 14:21

apart from natural code quality criteria (minimum copy/paste, no spaghetti, etc.) a good industrial code should always look a bit naive, a bit too verbose, like

int key = i;
const bool do_not_create = false;
Record r = cache.get(key, do_not_create);

as opposed to

Record r = cache.get(i++, false);
  • But does do_not_create = false mean “pass false as the do_not_create argument so that it will be created” or “pass false as the do_create argument so that it will not be created”? In a language where you can use argument names I would prefer cache.get (key:i, create: false); i += 1;.
    – PJTraill
    Oct 20, 2016 at 0:01

Perhaps an answer by illustrating the opposite would help (plus it's an excuse to get XKCD in here).

alt text

Good code is

  • simple to understand,
  • easy to maintain,
  • doesn't try to solve all problems only the one at hand
  • lives on for a long time without making developers look for alternatives

Examples include

  • Apache Commons
  • Spring framework
  • Hibernate framework

I'll simply go with "maintainable"

All code has to be maintained: no need to have that task made more difficult than necessary

If any reader doesn't understand this simple requirement or needs it spelled out, then that reader should not be writing code...


Good code is going to be different for each person and the language that they are working with also has an impact upon what might considered to be good code. Generally when I approach a project I look for the following things:

  • How is the project organized? Are source files organized in a clean manner and can I find code with out too much effort?
  • How is the code organized? Is is clearly documented what the code in the file does, such as through the use of a file header, or through the use of each class residing in its own file? Are there function in the file that are no longer being used in the application?
  • How are the functions organized? Is there a clear pattern to where variables are declared, or is it a fairly random pattern? Does the code have a logical flow to it and avoid unnecessary control structures? Is everything clearly documented with code being self documenting where need be and comments clearly expression the why and/or how of what the code is doing?

Beyond all of this, does the design of the application make sense as a whole? The code residing in the application can be the best in the world, but it might still be a pain to work with if the overall design of the application makes no sense.


Let me kindly disagree on the readibility. No, not completely: Good code should be readable, and that can be easily achieved with enough comments.

But I consider two kinds of WTF: those where you wonder if the programmer got further than programming 101, and those where you absolutely don't grasp the geniality of the code. Some code can look very strange at first, but is actually a very inventive solution to a hard problem. The second one shouldn't count in the WTF-meter, and can be avoided by comments.

Very readible code can be very, very slow. A less readible solution can give a manyfold improvement in speed. R is a great example of a language where that often is true. One likes to avoid for-loops there as much as possible. In general, I'd consider the fastest code the better code even though it's less readible. That is, if the improvement is substantial off course, and enough comments are inserted to explain what the code does.

Even more, memory management can be crucial in many scientific applications. Code that is very readible, tend to be kind of sloppy in memory usage: there are just more objects created. In quite some cases smart use of memory makes the code again less readible. But if you juggle around gigabytes of DNA sequences for example, memory is a crucial factor. Again, I consider the less memory-intensive code the better code, regardless of readibility.

So yes, readibility is important for good code. I know the adagium of Uwe Liggis : Thinking hurts and computers are cheap. But in my field (statistical genomics), computational times of a week and memory usage of over 40 Gb is not considered abnormal. So an improvement of twice the speed and half the memory is worth a lot more than that extra bit of readibility.

  • No rule/rules without exception Mar 18, 2015 at 12:41
  • 1
    Let me disagree with your disagreement: you say that in your field speed is very important and say that it is more important than readability. I disagree, you should strive to use the right balance. If speed is not needed, for example for a high level interface, you may prefer something easy to maintain, if speed is needed then I agree with you. Rather than hard rules it is better to use common sense and you should avoid premature optimisation anyway.
    – BlueTrin
    Mar 27, 2015 at 23:42
  • @BlueTrin Why not both brain-compile those hi-perf source codez, and also document the hell of what's going on there (right there in comments)?
    – mlvljr
    Mar 29, 2015 at 17:07

As far as it goes for me... I know I'm writing good code when a coworker that does work on another project comes along and is able to jump in and understand what I'm doing without me going over each block of code and showing what it is doing.
Instead of him saying, "Wait a minute, what?!" He's saying, "Oh, ok, I see what you did there."

Good code also doesn't have a lot of sneaky workarounds or 'hacks.' Lines when, while you're writing it, you're also saying to yourself, "I know this is not a good way to do it, but I'm just gonna have to do it this way for now. I'll remind myself to improve it later..."


There are lots of features of 'good' code, but the most important, IMHO, are readability and maintainability.

Your code will contain bugs, will probably be extended and re-used, and ought to be re-factored at some point - even if it is you re-visiting it, the chances are that you won't have a clue what the hell you did in the first place, to do yourself a favour and don't put any barriers in the way.

Sure, use that complex-yet-uber-efficient algorithm, but make sure you spend a little extra time documenting it, but otherwise make your code clear and consistent.

Not the answer you're looking for? Browse other questions tagged or ask your own question.