We maintain a code review checklist which omits things such as styling and other stuff that can be automated. The focus is more on ensuring that the functionality is achieved and code is in a maintanable state. To this effect, we have all of the items that you have mentioned. What we have is a fluid list i.e the checklist is updated every once in a while when a behavior appears or disappears (what I mean by that is if all of the developers are running findbugs and Unit tests before committing we remove it off the checklist but if we observe that the methods are longer than let's say 25 lines in a number of reviews, we then add it to the list).
So, my recommendation would be to start off with a list based on what is observed in your dev environment and tweak it accordingly when there is a need. Here are some of the items we have in our list (all of these are based on our dev teams code reviews)
- Are there magic numbers in the code? Need to be converted to constants
- Did the method name convey it’s intent Or variable name convey it's intenet
- If there are queries, are they using parameter binding (use of prepared statement)
- Are the variables declared at the narrowest scope possible?
- Have all resources that are used returned back correctly – db connections closed, files closed etc
- Does the code cover the story/task in question completely
- Are the number of parameters in the method less than <4>