Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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"?

share|improve this question

closed as not constructive by bigown Dec 28 '10 at 19:16

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

11  
Good code is if you look at it after two years and your first thought isn't "Dude, wtf". –  Bobby Nov 7 '10 at 19:16
    
add comment

13 Answers

WTF's per minute

(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.

share|improve this answer
1  
We have this stuck on our whiteboard at work :-) –  rmx Nov 7 '10 at 11:03
1  
@Cape Cod Gunny Was in an Uncle Bob's book also –  mlvljr Nov 7 '10 at 11:34
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 '10 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 '10 at 17:43
3  
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 '10 at 17:49
show 5 more comments

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.

share|improve this answer
    
So how well the code actually does its job is not important? –  rmx Nov 7 '10 at 11:04
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. –  rmx Nov 7 '10 at 11:27
1  
@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 '10 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. –  pillmuncher Nov 7 '10 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 '10 at 12:15
show 8 more comments

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

share|improve this answer
    
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 '10 at 11:48
    
Check this : goo.gl/hdQt8 –  Chankey Pathak Nov 7 '10 at 12:19
    
Code can be bug free? –  Casey Patton Aug 2 '11 at 16:41
    
No it can't. (Practically) –  Chankey Pathak Aug 3 '11 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 '12 at 3:09
add comment

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);
share|improve this answer
    
+1 i agree with being verbose –  Vishnu Nov 8 '10 at 12:55
add comment

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.

share|improve this answer
1  
"The customer is happy" is orthogonal to this. –  user1249 Nov 7 '10 at 12:19
    
@TRA - If the customer is happy that means you understood the requiremnts and provided a solution they expected. –  Cape Cod Gunny Nov 7 '10 at 12:25
4  
sure but bad code can do the same. –  user1249 Nov 7 '10 at 12:50
add comment

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.

share|improve this answer
1  
very interesting, +1 –  Yar Nov 7 '10 at 23:56
add comment

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
share|improve this answer
add comment

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...

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
8  
"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? –  hasenj Nov 7 '10 at 23:19
3  
+1 Great analogy! –  rob Nov 7 '10 at 23:51
2  
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. –  Yar Nov 7 '10 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 '10 at 4:15
add comment

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.

share|improve this answer
add comment

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..."

share|improve this answer
add comment

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.

share|improve this answer
add comment

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