Re: Code formatter

[Graham Percival]

On Fri, Nov 13, 2009 at 08:41:06AM -0500, Chris Snyder wrote:
> There is one thing that bugs me about this discussion (and others) - it  
> seems like sometimes improvements are rejected as being "not good  
> enough," even if they're still an incremental improvement. Wouldn't  
> running all of the C++ code through astyle still be an improvement over  
> the current situation? It wouldn't prevent future formatting mistakes  
> and it wouldn't help with the Scheme and ly code, but it would still be  
> a step in the right direction.

1) running astyle will change lines of code.  This makes the
history harder to look at... if we want to know who wrote a
particular line (say, "there seems to be a bug here; hey Joe, why
did you write "if (x = 3)" ?"), then it will appear that *you*
were the last person to change that line of code.  Even if all you
did was run astyle on it.

Yes, it would be nice if we had diff tools that looked at
non-whitespace changes to code.  Yes, such tools do *exist*, but
they're not widespread.

So we don't want to run one tool, look around, run another tool,
look around, and then finally choose a third tool to use.


2) many programmers view code style in a highly personal,
quasi-religious manner.  "My first supervisor used two spaces on
the next line after a curly brace, so that's what I will do!"
If you've looked at the previous discussion, then you'll see that
even Han-Wen and Jan have different views about what we should do.

Basically, pretend that you're negotiating a merger of Anglican,
Roman Catholic, and Protestants.  Sure, they all agree on the
basic points -- just like everybody here agrees that a single code
style is good and we all want lilypond to be better -- but there's
a lot of details in how we differ.  And many people will feel
quite personally about their particular differences.


Any automatic tool will probably result in everybody having to
give up at least one closely-held belief (whether it's the
supremacy of tabs, or lining arguments up after an opening brace,
or how a switch/case command looks, or whatever).  So when you
propose a tool, we need to know what it will change.  And for all
those changes, we need to be convinced that it's an ok change.

Sometimes, the automatic tool will just make existing
badly-formatted code meet our own standards.  In other cases, it
*will* change the standards.  Some of us won't care; others will
care deeply.

Cheers,
- Graham