Exceptional coding style

[Jonathan M Davis]

On Friday, January 18, 2013 10:20:58 dennis luehring wrote:
> Am 18.01.2013 10:10, schrieb Artur Skawina:
> > Which is my point. An autoformatter makes the bad code look good, but does
> > not change its quality. Hence use of such a tool as part of the std dev
> > process should be strongly discouraged, not encouraged.
> 
> bad code can't look good by pretty-printing - its the semantic not the
> style...
> 
> so you can concentrate your analysis completely on the semantic if an a
> fulltime 100% working autoformatter would be always active
> 
> and if something like this would become a standard it wouldn't be that
> hard for me as a freelancer to switch codeing-style from company to
> company, department to department - all the while 10 TIMES a year :)
> 
> and that would reduce all this sensless dicussion about coding style
> down to an (sometimes not all loved) standard
> 
> in the end the semantic of the code is all that counts: style a, b or c
> isn't what keeps the world go round - unixstyle,Qt-style,mfc-style,etc.
> they all are ~good but different

Formatting can have a huge effect on code legibility. There are plenty of cases 
where slight formatting changes don't make that big a difference, but some 
really can (e.g. where the braces go), and many small differences can add up. 
For instance, I've known folks who used lots and lots of parens (generally not 
relying on operator precedence at all), and that made the code _much_ harder 
to read. Or having too much or too little whitespace can have a large effect on 
how the code looks and how easy it is to read. It's a _highly_ subjective 
issue, but I think that it's misguided to think that code formatting doesn't 
matter. True, the semantics matter more (if nothing else, semantics matter to 
the compiler, whereas formatting doesn't), but it still matters quite a bit.

- Jonathan M Davis