How can we identify "good code"?

Question

There's already a great long post on identifying bad code (see Code Smells).

I'd like to ask for the reverse. Do you know any good procedures or checks to identify good code? Quick pointers such as "the class definition fits on one page together with it's documentation", or "the code can be effortlessly re-used" would be great, longer thought-through answers about code review or metrics are also welcome.

I'd like to get some input on this to build up to a positive-reinforcement code review and analysis at my work, because I feel that would be more productive than pure criticism (though both will likely be combined in the end).

Answer 1

• It's easy to tell what functions/classes/variables do based solely on their names.
• Implementations are expressive -- no space is wasted in getting the semantics of an algorithm through to the reader, and there is very, very little repetition.
• There is good unit-test coverage.
• The program builds itself.
• Comments explain WHY something is done, not WHAT is done.
• The style of the code is consistent (no matter who is doing the writing)
• The code performs well.
• It's not Bad Code. ;-)

Answer 2

1st most important point is whole code should be consistent i.e. it should follow same guidelines and naming convention everywhere.

Answer 3

The cyclomatic complexity is a good indicator, where low = good and high = bad.

If low, this doesn't mean the code is good.

If high most certainly the code is badly written.

Answer 4

I like a code, when i am able to read it like a book. With headings (commentin the next method/block/paragraph), paragraphs (spare lines between logical parts), sentences (one statement per line), correct spacing between words (i.e. variables) and interpunctation (i.e.braces), nace naming conventions, no repetitions.

Answer 5

Good code makes you feel warm and fuzzy while you read it.

It makes you feel smarter (not more confused).

Answer 6

It's a good question. First of all in your company should be a document describing all formal things about formatting code and so one. It's first place to find rules to compare the code with.

I you don't have this kind of document, most likely, everyone codes in different way and direct checking style of code is worthless. Because there is no place to refer to, there is no agreement on how code should look like.

Second thing is how code is organized. It's harder to analyze code from this perspective. I f you agreed to design code in much the same way in company so everyone can read everyone else code, than you have from where to start. If not - you should create such document.

If you complete documentation based on discussion with programmers (avoid religion wars) than you can check code in order to find places where more care can be added to adding code to your solutions.

It's long way, because you should start from discussion, documentation and on the end on code reviews, but it's worth doing. Most programmers like to know they code in the proper way.

Answer 7

Being from the .Net side of things myself, there's a really great book that helped me in my quest for good code. Framework Design Guidelines. It really emphasizes consistency in coding standards. It's not talking so much about "loosely coupled" solutions, but more about "what type of things should be methods vs. what things should be properties" - as well as a myriad of other things. It truly helps you to understand the mindset behind the development of the .Net framework and thus be able to build applications against it better.

Answer 8

Good code is hard to define but I think as rules of thumb a good code is easy for maintenance : 1) Anybody can jump on it and modified it, 2) Name convention, good cohesion,

But if you want a deeper and less personal answer I suggest to refer to Mc Call (1977) and his software attribute about software quality:

• Maintainability, the ability to find and fix a defect.
• Flexibility, the ability to make changes required as dictated by the business.
• Testability, the ability to Validate the software requirements.
• Portability, the ability to transfer the software from one environment to another.
• Reusability, the ease of using existing software components in a different context.
• Interoperability, the extent, or ease, to which software components work together.
• Correctness, the functionality matches the specification.
• Reliability, the extent to which the system fails.
• Efficiency, system resource (including cpu, disk, memory, network) usage.
• Integrity, protection from unauthorized access.
• Usability, ease of use.

These are good point to figure out if the whole code (the software) is "good" or "bad".

You can find more information at SQC Software Quality

Answer 9

As noted by tomaszs if your company has a document defining what "good" code is then you are pretty much set as it is spelled out what good code is going to be for you. However, in a lot of situations, a set of coding guidelines might not cover everything that would go into creating good code. Some of the key area's that I look at to determine if code is good are as follows:

• Is it well formatted? - One of the first things that stand out when looking at good code is that it is constantly formatted. Code that is inconstantly formatted tends to cause future developers to run into issues when trying to track the code logic and can result in time being wasted. StackOverflow has some questions worth reading on this topic tagged with "formatting" as well as "coding-style."
• Is it well commented? - Poorly commented code can cause future developers, including yourself, to lose time when trying to fix bugs or implement new features. StackOverflow has quite a bit of information out there if you search the "commenting" tag.
• Is the code self documenting? - Comments should not be seen as a catch all for all of the code documentation, the code itself should be self documenting. Variable, function, and class names should make sense and give an idea of what they do just by looking at them.
• Is the code fragile? - Poor code can still be well formatted, commented, and self documenting, but good code should never be fragile and areas of code that can be sensitive to faults should be appropriately coded to be as fault-tolerant as possible and issues should be well documented. One area that you can look at to get a quick idea as to the quality of the code is how sensitive it is to user input, if the application crashes because the user enters data in a given way, then something might be wrong with the code as a whole.
• The algorithm logic is generally clear, or if not possible, well documented - This one can be a bit subjective, but good code will generally have algorithms that are either clear in what they are doing, or well commented in the case of complex algorithms. Generally, something that I look for when reviewing code, is how fast I can understand an unusual algorithm or be pointed to more documentation on it. For example, if you need to implement code to compute a square root you might not want to comment each operation as it would clutter up the code, but the code should still have something saying which technique is being used, deviations from norms, and why the code was implemented as opposed to using a library call.

Answer 10

1 - It works

2 - It keeps working

3 - Any dev can understand why

Answer 11

Not sure if I'd agree with some of the posts here (would add a comment but I'm not famous enough ;) )

Once read a PM book that said developers like tricky code as once they've slaved over a hot debugger and understood it, then they feel smart...

So, trickyness of all kinds is to be deplored. Good code is simple code, naming convention issues etc are way down the field.

Answer 12

If your non-technical manager can understand it.

Answer 13

One thing that comes to mind that hasn't really been mentioned yet (but possibly more a style issue than a "good code" issue) :

• If you can figure out almost everything from just the name of the class / function. That means you really nailed down the concept and the naming.

Answer 14

Along with the broader qualities that have already been posted, for a more down to earth check list of good code, I look for:

• makes use of the DRY (Don't Repeat Yourself) Principle, SDP (Stable Dependency Principle) and other programming principles
• code is grouped into logical groupings with comments to explain the sticky parts
• variables are declared close to where they are used
• varaibles are tightly scoped so they exist only for the needed amount of time and no more
• makes good use of the compiler to easily check for errors (using const/readonly when appropriate) and for type-safety
• uses generics and templates instead of nontype-safe structures
• classes are loosely coupled
• good use of interfaces
• easily unit testable
• good separation of UI from logic

Answer 15

Good code is very often small code...

Answer 16

For me, good code teaches me things I do not know and bad code teaches me things I do know because I (so do countless others) have written bad code sometime or the other in their life :)

Answer 17

Good code is no code at all.

Answer 18

Many good answers here, but remember there is good code that fails any of the 'tests'.

Take, oh, say, sendmail. Changed the world, runs on rather a lot of servers, but probably does not match some folks idealized namming conventions.

Answer 19

My favorite sign is a complete and total lack of magic numbers. Preferably initialized in a block with meaningful names, but I'll settle for inline comments if absolutely necessary.

Answer 20

Good (elegant, beautiful) code is normalized:

http://theprogrammersparadox.blogspot.com/2008/11/code-normal-form.html

At least to third, if not to forth or fifth normal form ...