On Wed, Jun 17, 2015 at 6:29 PM, Robert O'Callahan <rob...@ocallahan.org> wrote:
> As an experiment, we declared the coding style of rr to be "whatever > clang-format produces with rr's .clang-format file" (which was tweaked to > resemble Mozilla style, including an 80-char line limit). Overall I've been > very happy with the results. Sometimes you get suboptimal linebreaking > decisions, but that's small potatoes compared to the joy of not having to > think about code formatting when you're reading or writing code. I'd be all > for doing something similar in Gecko. > +1 Assessing style compliance as == clang-format(whole file) is by far the easiest to implement. I'd be in favor of a flag day (or set of mini flag days) where we mass rewrite the tree with clang-format's output. As far as keeping things in compliance, I'm not opposed to running clang-format on hg.mozilla.org as part of a push hook - I think it is fast enough that it won't introduce too much latency. If that doesn't work, Autoland could run clang-format automatically as part of landing commits. Mercurial now has support for server-side rebasing/rewriting during push operations. As of this week, this is deployed on hg.mozilla.org. Essentially you push up commits, the server changes them, and the rewritten commits are pushed back to the client. One can imagine a world where clang-format and similar functionality occur at push time. We could e.g. have the MozReview repository auto format code as you submit it. Of course, if we go all in on formatting tools, developers should have this integrated into their local workflows so we don't need server-side assistance (it's possible to reprogram the "save" action in many editors). But not everyone will do this, so I reckon we need defense in depth. First thing is first: what are the blockers to mass rewriting mozilla-central with clang-format's output? _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform