Standards and enforcement of same is (usually) a symptomp of the "interchangeable morons" school of management. It presumes that all problems have a (ayn rand-ish) uniform solution that all _programmers_ will process identically.
A small number of "do not do"s with a "unless you have good cause" _guidelines_ are reasonable, but something as firm as a "standard" is a great way to make your great programmers no better than your worst over time.
Standards often contain bugs themselves. Things that create a hidden cost on the programmer and the program that can bog both down.
Even Microsofte eventually abandoned their "Standard" for putting the variable type as encoded dirt on the front of their varialbe names such as "lpintThingy" having plagued their code with Thingies that are no longer long pointers to integers and that cannot be globally searched and replaced because that hazards destroying other code.
Combined rule failure (use getters and setters + don't put member function definitions inside of class definitions => what would be a register load operation becomes an optimization resistant far call across translation units ** every dang time you set or read a scalar).
If you cannot trust your programmers to write good code then making them format it so it _looks_ like good code is a wasted effort.
If you cannot trust your great programmers to write great code eventually they will stop even trying to do so and you will be left with a hassle avoiding idiot or someone looking for a new job.
If you cannot trust your new programmers to understand your previous code then your new programmers are probably inferrior to your older coders.
If you are not winnowing out the _bad_ programmers via rational code review then your management is useless.
All but the most rudimentary coding guidelines are productivity and creativity and performance murderers.
Every company eventually realizes this, on and off, for a while, each time a management team ages into a job, and then forgets it again when they hire new managers.