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"?
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.
(original)
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.
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.
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.
You know you write good code when...
How do you measure whether the code is good...
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
bug free
reusable
independent
less complex
well documented
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
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.
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);
++i;
as opposed to
Record r = cache.get(i++, false);
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;.
Perhaps an answer by illustrating the opposite would help (plus it's an excuse to get XKCD in here).
Good code is
Examples include
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:
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.
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.
