in reply to On Coding Standards and Code Reviews
The list is too long and the potential conflicts between some of the various standards you've cited need to be explored. So too, the match between the list and the problem areas for your particular team. The key is focus: too much information is equivalent to no information at all.
Conflicts between "best practices" isn't necessarily bad: good architecture is often a delicate balance between competing principles (e.g. abstraction and simplicity). In fact, discussing and exploring competing principles as a team is a great way to develop good programming judgment about which principles should apply when.
I also noticed that nowhere in your list of sources did you mention interviews with your team members. There is another thought you might want to consider that came up in a recent discussion between tilly and myself: mentorship. Programming is as much an art as a science and if there are experienced members of your team with proven design and implementation skills, it is a good idea to ask them for their insights and to encourage them to coach the less (software wise) mature members of the team. Sometimes the bluebird of happiness is flying around in your own backyard. A design principle taught and tied to the experience of an old hand and a member of the team is going to carry a lot more weight than the rhetorical pronouncements of the latest gurus.
Best of luck with this project, beth
P.S. If you have a manager that doesn't get that last bit (rhetoric vs. ...) I have a nice article from Harvard Business Review on the Rhetoric of Action that I can dig up for you - and I'm sure I can find others as well. Just msg me.