However, there are many different tools and IDEs that will format to whatever standard the programmer prefers.
Good luck with that. My experience, there are a tiny number of tools (zero!) that can properly reformat code from format X to format Y. There are just too many things that get in the way. Tabs vs spaces, multi-line statements, etc. Just look at GNU's implementation of the C++ standard library files. What you can do is make your IDE do is to always use spaces instead of tabs and just don't bother reformatting foreign code. Now your code looks the way you like it, and the foreign code looks the way the original author wrote it.
A specific indentation style is the last thing a coding standard should specify. That's verging on starting a programming religious war. IMO, a coding standard should specify a reasonable suite of acceptable indentation styles, but leave the specifics to the authors of a package. Indentation style is, or should be, a tiny part of a coding standard. Rule number zero of coding standards: Don't sweat the small things. Indentation style is a small thing.
Bigger things:
- How do I name things?
- Are certain parts of the language off limits?
- Does the code need to compile clean, and with what compiler settings?
- Does the code have to pass certain metrics?
- What kind of testing is needed?
- What kind of documentation is needed, both in the code (comments) and elsewhere?
- Most important, how do I get a waiver to the standard?
Addendum
Perhaps even more important is what not to put in a coding standards. Topics such as how to write requirements do not belong in the coding standards. Details on testing do not belong, either. A project should not use the coding standards as a stand-in for the project management plan, the test management plan, the verification and validation plan, etc. The goal of the coding standards is to improve code safety, quality, understandability, maintainability, and other "ilities". There are lots of ways to ensure that this won't happen. Just a few: Making the standards a book as complex as some country's tax laws, inciting programming religious wars, having bad naming conventions.
Coding standards can have unintended consequences. Example: Some fool of a project engineer is going to interpret the "no magic numbers rule" to mean that if (index == 0) {...}
and for (ii = 0; ii < 3; ++ii) {...}
must be changed to if (ZERO == index) {}
and for (ii = ZERO; ii < NUMBER_OF_DIMENSIONS_IN_THE_UNIVERSE; ++ii) {...}
Don't laugh. I've seen it happen. Nowadays when I write a coding standard it's a "no magic numbers guideline" rather than a rule to counteract this kind of foolishness.
The coding standard is not the number one defense against bad programming style / dangerous coding practices. The code review is. Despite many years of automation, there is still nothing better than a having somewhat subjective set of human eyes look at and pass judgement on a chunk of code.