The currently topmost voted answer is IMHO not bad, but it is actually not answering the OPs question (as Michael Durrant admitted by himself), so I try to give an answer which does:

> I also understand that comments should explain why the code does what it does, not how.

> Given all this is it even possible to write good coding standards that capture this idea?

Obviously you can write a **checklist for your code reviews**, containing questions like 

 * "if there is a comment, does it explain why the code does what it does?"
 * "is each line of the code - in its context - either self-explanatory enough that it does not need a comment, or if not, is it accompanied by a comment which closes that gap? Or (preferably) can the code be changed so it does not need a comment any more?"

If you like, you can call this a "coding standard" (or not, if you think the term coding standard should be reserved for a list of braindead rules, easy to answer if they are fulfilled or not, how the formatting of the code should look like, or where to declare variables). No one hinders you to have the focus of your checklist on *semantical* questions, instead of going the easy route and put only *formal* rules into it.

But at the end of the day, you should be sure your team needs such a checklist. To apply such questions you need programmers with some experience as reviewers, and if you have such guys, it is questionable if this checklist will really help them. But that is something you have to work out together with your team.