I thank you for the effort and up-voted you accordingly! I do have some remarks though.

Most of the general guidelines are too general to be of any use. How are you going to address them? What do you need to do when, and how are you going verify they have been met?

Take for example Robustness, how to address that?

What I miss is the Software Development Life Cycle, the process. You need to make the abstract statements tangible and embed them in a process. In my experience this is the only way to make it work, especially when projects get bigger and/or the SW has a zero fault tolerance architecture. i.e. SW for a nuclear plant, medical applications etc.

Also where does architecture comes in? What I mean is the general guidelines may conflict with each other. Then you will have to determine what is more important, likely on a per project basis. I like to view things like Robustness, Efficiency, Maintainability, Scalability, etc as “Quality Attributes” in the architecture and give them weights depending on their importance (depending on the specific project). With a simple excel sheet you can make a more founded decision on what to focus on. There are always restrictions (budget, time,...) and chances are you can’t do all things in your list. Focusing on the important ones and doing them good makes more sense then doing all of them but half.

I've been asked to prepare some guidelines on coding standards and code reviews

Coding Standards and Code reviews are typically instruments of the (much) wider area of Software Quality Assurance. The code reviews they fall in the SQA activity category SW verification/validation.

I don’t know the size of your company but I assume it must have at least one QA guy, maybe even a full-blown QA department. In any case QA people need to be involved in these type of activities.

HTH