1. Every fixed defect on a deployed product has tests added to prevent regression.
The worst thing you can do in this business is to have the same problem twice. Prevent it – our clients and users will usually understand if a bug happens the first time.Not ever, if it happesns agian.

2. Every design choice should yield the most simplistic design possible for the need of users at the current time. No guesses for future functionality were disigned into the application.

3. This paradigm is just as much for Project Manager as it is for Developers – but both types of people on a project have a responsibility to ensure that this is followed. Although Chapter 4 of Getting Real explains it better than I ever could – to sum it up. If you make guesses, rather than designing to facts, invariably, some of those guesses will be wrong. Some might be right , but any designing and development aht are for wrong guesses make things more complex, harder to fix, and harder to improve.
Instead, code to what you know is true, launch early, watch users, and iterate quickly. That’s on of the major benefits of hosted software (web apps) over distributed software (desktop apps) – so use it to its full advantage.

4. All logic duplicated between two or more modules/classes has been turned into a gemified module.

5. All functionality used in two or more models has been turned into a library/module.

6. Code has been aggressively DRYed during development. Make helpers. Make modules. Just keep doing it.

7. All model and variable names are bothe immediately obvious ( to a new developer) and as short as possible without using abbreviations. Naming is hard. Particularly for developers who are immersed in an application – what’s obvious to you when you’ve loaded the entire context of the application into your brain, will not be obvious to you later or to a new set of eyes. Don’t ruin this immense strength! If you can’t think of an ingenious, clear, and short name immediately, finish coding your method, and then try to unload the entire context you have while deep in coding. Put a TODO in and rename your variable or method name at the end of the day.

The hope is that every item on the checklist is so obvious to the more experienced Java developer, that it’s not worth mentioning – but that to new developers, the items on the list are non-obvious, and require some explanation. So here goes:

I certify that all of the above is true for my project.
[Printed Name] Signature

This is extended from http://www.matthewpaulmoore.com/articles/1276-ruby-on-rails-code-quality-checklist

I think these items are not only for Ruby on Rails but also work for other development, like Java, ASP.NET