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.
