On 01/18/13 09:48, Walter Bright wrote:
> On 1/17/2013 11:58 PM, Artur Skawina wrote:
>> Sane, but badly formatted code is much preferable to bad, but pretty code.
> 
> Offhand, I can't remember ever running across bad but pretty code.

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.
Having it can be useful when refactoring, yes.

If /formatting/ conflicts appear during merges, then it's a sign of either a) bad code, or b) bad process. Papering over either problem with an autoformatter is not the right fix.

artur

On 01/18/13 09:58, Timon Gehr wrote:
> On 01/18/2013 09:48 AM, Walter Bright wrote:
>> On 1/17/2013 11:58 PM, Artur Skawina wrote:
>>> Sane, but badly formatted code is much preferable to bad, but pretty code.
>>
>> Offhand, I can't remember ever running across bad but pretty code.
> 
> Some of the worst code I have seen has been consistently formatted.

Mechanically? ;)

artur

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

Am 18.01.2013 10:20, schrieb dennis luehring:
> so you can concentrate your analysis completely on the semantic if an a
> fulltime 100% working autoformatter would be always active

another nice effect of an autoformatter would be the newcomer-style - only the semantic is normaly total shit in the very beginning but the style is correct and the semantic is getting better over time, why to work on both sides: code semantic AND coding-style - isn't the first enough for an whole programmers life to learn?

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

Am 18.01.2013 10:29, schrieb Jonathan M Davis:
> 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.

don't get me wrong - coding style is very very important

but without an forced formatting standard you got following problems:

-many different coding styles in each company, sometimes even on deparment-level, every project
->hard for project jumpers, always a need for everyone to define a standard

coding style itself: _highly_ subjective emotional thing mostly hard to discuss in any way
->a forced standard could de-emotionalize the them a little bit

-permanent reformatting when integrating foreign code

a forced coding style could help to define a better base standard that many will just use because of its existence

etc...

On Friday, January 18, 2013 10:45:46 dennis luehring wrote:
> Am 18.01.2013 10:29, schrieb Jonathan M Davis:
> > 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.
> don't get me wrong - coding style is very very important
> 
> but without an forced formatting standard you got following problems:
> 
> -many different coding styles in each company, sometimes even on
> deparment-level, every project
> ->hard for project jumpers, always a need for everyone to define a standard
> 
> coding style itself: _highly_ subjective emotional thing mostly hard to
> discuss in any way
> ->a forced standard could de-emotionalize the them a little bit
> 
> -permanent reformatting when integrating foreign code
> 
> a forced coding style could help to define a better base standard that many will just use because of its existence
> 
> etc...

I've worked at places with strict coding standards which included formatting rules (in some cases, having to use autoformatters), and I've worked at places where strict coding standards were not used, and I've always found the places without strict coding standards to be far more pleasant. Things like APIs should have standards (e.g. functions are always camelCased, and types are PascalCased), but in general, I'm against formatting standards. For the most part, keeping files reasonably internally consistent should be enough. About the only formatting rules that I think should be strictly adhered to in general are bracing rules and spaces vs tabs, and I'm _very_ opinionated about those, but it's just plain more pleasant to leave the others to the individual developers with the caveat that code within a file should be reasonably consistent. And for the most part, that's what we've been doing with Phobos.

- Jonathan M Davis

On Friday, 18 January 2013 at 09:10:38 UTC, Artur Skawina wrote:
> On 01/18/13 09:48, Walter Bright wrote:
>> On 1/17/2013 11:58 PM, Artur Skawina wrote:
>>> Sane, but badly formatted code is much preferable to bad, but pretty code.
>> 
>> Offhand, I can't remember ever running across bad but pretty code.
>
> 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.
> Having it can be useful when refactoring, yes.
>

That is completely erratic reasoning. What you state here is that the 2 issue are orthogonal, and that code quality is an irrelevant topic when it come to pro/cons of a formatter. You didn't demonstrate in any way that it is to be avoided.

> If /formatting/ conflicts appear during merges, then it's a sign of either
> a) bad code, or b) bad process. Papering over either problem with an
> autoformatter is not the right fix.
>

Using an autoformatter is a sure way to fix the process if such merging error occurs. The other way is to ask everybody to spend their time formatting in a given way. Anyone that have managed a project KNOWS that asking everybody to do something is not gonna make it, either because people don't care or because people make mistakes.

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.

On Friday, 18 January 2013 at 10:30:33 UTC, deadalnix wrote:
> If you believe you know operator precedence, you are probably wrong. And even if you are right, most other programmer don't.


They're not /that/ bad...

+ - * / %  are like in math
<< >>      are harder, but all you need is to recall that cout << x + 2;
           works as written
|  &       are just like in math (or is addition, and is multiplication)
^          is in between | and &
|| &&      are just like in math (or is addition, and is multiplication)