It is exactly that. Which is intentional because it puts style and correctness in the same domain. When they are not, it makes functional interpretation of what’s in front of you more difficult.
Prettyprinting and correctness should not be in the same domain.
Without correctness, prettiness is irrelevant - unless you are an artiste
With correctness, given a suitable language and IDE, prettiness is merely two clicks away! We're not working with 5 channel paper tape on 5cps telytypes anymore!
Prettiness ought to be easy.
C case statements are a brilliant little hole where this goes to hell.
There are far worse problems with C than that!
Also how do you know your code still works if you don’t test it?
You can't test quality into a product.
Hence goto fail mentioned earlier which would have been picked up if they had a test suite that was worth more than a bag of crisps.
But throwing all of this aside, where do you think the biggest risks are? Mostly in interpreting the problem domain competently. Case in point I watched some code destroy 100k archived financial documents once because a business analyst misread archival requirements. The code did what it was told efficiently and without mercy. Edit: try and understand OAuth2 without leaving a hole the size of a bus in something ![Smiley :)](https://www.eevblog.com/forum/Smileys/default/smiley.gif)
That's why validation and verification are two separate disciplines. Figuring out what to do
ought to be more difficult than doing it.
There are many pitfalls to creating and maintaining something that is correct. Pitfalls shold not be introduced unnecessarily.
Regrettably some tools introduce problems that other tools avoid. Such tools shold be deprecated.