View mode: basic / threaded / horizontal-split · Log in · Help
January 18, 2013
Re: Exceptional coding style
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
January 18, 2013
Re: Exceptional coding style
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
January 18, 2013
Re: Exceptional coding style
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
January 18, 2013
Re: Exceptional coding style
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?
January 18, 2013
Re: Exceptional coding style
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
January 18, 2013
Re: Exceptional coding style
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...
January 18, 2013
Re: Exceptional coding style
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
January 18, 2013
Re: Exceptional coding style
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.
January 18, 2013
Re: Exceptional coding style
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.
January 18, 2013
Re: Exceptional coding style
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)
13 14 15 16 17 18 19 20
Top | Discussion index | About this forum | D home