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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel