Exceptional coding style

[deadalnix]

On Friday, 18 January 2013 at 09:30:51 UTC, Jonathan M Davis 
wrote:
> 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.
>

If you believe you know operator precedence, you are probably 
wrong. And even if you are right, most other programmer don't.