Like many others, I'm very impressed with what you've written. I see it as a survey of the things we might possibly want to consider when doing reviews and such.

I recently worked in an organization which had a requirement of tool-assisted review for every piece of code that went into version control. I can say for certain that a much smaller list would be more useful for focusing reviews.

Picking a single coding standard that everyone can work with is a very good idea. Separate from that a (short) checklist of things to be aware of when reviewing is helpful.

Were I beginning this kind of a process (again), I'd probably start with your list and start paring them down. Anything that everyone does already (or strongly agrees with) does not really need to be on the checklist. Anything that everyone agrees with and tries to do should be on the list. Start with the low-hanging fruit. What gives the most advantage with the least disagreement?

In my experience, the bigger the list the more likely to generate one of two reactions:

• "That's nice." and everyone ignores it
• "I disagree with this one little nit, so I won't do it."

Generating a shorter checklist from your overall list is less likely to trigger either of these reactions.

The great thing about your list, for me at least, is that it gives a broad overview from which someone could pick what is important for their group.