Coding standards are only meaningful if they help you write code. So they just need to keep your code consistent (ie if someone puts m_ for variable members and someone doesn't, it can take longer to grok the code than if they all used the same style).
That's all they (should) do, so just pick up your existing code and make sure your team codes to the same style.
I like to think of it like cartoons. If you become a cartoonist on the Simpsons, you have to draw eyes in the official way or everything looks pants, but if you go to Family Guy, you have to draw them differently. Neither way is wrong.
Too many standards are about meaningless restrictions, written by people who don't code themselves (or consider themselves too good to keep to them). Others try to teach you how to code. Neither has its place in a good standard, those just make it easier for you to look at some code and understand what its doing.
eg. my standards include rules for naming directories - you will always have your code in a directory called the same name as the project, and all binaries go in the bin subdir, with all config files in the same place, and a changelog, etc. All simple stuff, but I guarantee I'll never find a project called something different with its binaries in the root directory where I don't know what changes were made to it. Simple, easy stuff that makes a huge difference.
