On 16 July 2017 at 21:15, Jean-Marc Lasgouttes <lasgout...@lyx.org> wrote:
> Le 16/07/2017 à 20:51, Scott Kostyshak a écrit : > >> "no debate" is good, but we want even more than that. We want a few more >> "yes let's go for it!" before we impose a new style. I think we got >> support from Kornel, but we would want more to go forward. There are >> other costs to changing many lines of the source code, such as "git >> blame" not being as easy/helpful. >> > > Indeed, my original message was about doing things that had a moderate > price tag attached to them. Imposing a style is IMO too expensive for us at > this point. I'm definitely not looking to impose a new style and I'm spending time to get close to the "existing" formatting style. I used quotations marks around "existing" as there's a bit of variation in what's currently used. Here's my thinking/planning: Once I'm close with a .clang-format file, I planned on assessing/presenting how much impact applying clang-format would have on the code base, as well as show what it'd look like. But also give some alternatives for implementing it, e.g.: - applying to all files at once - for now only apply to source that haven't been modified in a long time - for now only apply to source where there's only minor/trivial formatting change (this is conceptually similar to Richard's removal of trailing whitespace) - only add the .clang-format, letting developers use it as they please when preparing patches - suggest use of clang-format as part of a pre-commit hook, either on an entire source file or only on the changed parts. (there's a cute command: git clang-format) I need to think/read a little more on these alternatives, and see how they'd interact with the code before I could recommend one. Speaking of reading/thinking, Scott's right about that there can be a cost associated: - the time I'm putting in, which is quite a few hours actually but I'm enjoying it and learning things - effect on e.g. "git blame" - risk of introducing errors (I think I've got that covered though) - cost for developers with pending work in their own branches - cost of issues related to differences between versions of clang-format (I'm currently looking at this, by comparing the result of using ver. 3.8 vs. 3.9 vs 4.0 vs. 5.0) - ? /Christian
