My view on standards, whether for programming or any other team-work related matter, is that you must have some clear and well-understood principles which will be enforced in any case. If it has exceptions it should not go in the standards. The standard may be controversial, but once someone (with the power to do so) decided it is the standard, there is no discussion and the team follows it or you get out of the team.

Of course that means that the team members must be able to follow the standards and it is my experience, if you have more than 5 principles/rules/standards to follow, you are too likely to miss one and people will understand/accept that you missed one. That is a slippery slope and before you know it everyone will do again as they did before and not follow any of the rules.

So pick five (three is even better) practical and concrete principles, rules, standards, best practices, ... post them in a conspicuous place and rigidly enforce them.

Things like "correctness comes first" is not a good principle: if it is not correct it is wrong and it simply doesn't count. This is a meta-principle or pre-condition or part of the environment and comes before you even consider your rules.

"Robustness, Efficiency, Maintainability" is too vague and cannot be enforced.

"Benchmark before you optimize", "Log all errors" and "The result of every file operation or API call must be checked, and unexpected results handled." on the other hand are examples of good standards and are easy to maintain and enforce.

If you can settle on five general rules, maybe you can add three for each of the different languages.

Lay-out should be entrusted to a code-prettifyer such as Perl-Tidy or similar, rather than put this in a rule-set. Then everybody can code as they please and before they check in their code it gets transformed into whatever form or layout is required. Some code-repositories can even do that automatically. If you cannot entrust it to a code-prettifyer, forget it. Do you really want to check the lay-out of someone elses code for the rest of your career?