On Sat, 2014-11-01 at 20:50 -0400, Steve Dougherty wrote: > On 11/01/2014 07:00 PM, David ‘Bombe’ Roden wrote: > ... > > I’m not a big fan of these single large commits that reformat all > > source code at once. As Google’s style guide mandates a little bit > > more than just whitespace and bracket position (e.g. that overloaded > > methods/constructors must not be interrupted by other methods, or > > that the order of fields and method must conform to some logical > > order, i.e. not a chronological order) most of the code must be > > manually checked and potentially corrected. > > > > I wouldn’t really touch the existing source code immediately but make > > sure that a) new source code conforms to the style guide, and b) > > touched code is reformatted: at least edited methods should be > > reformatted, preferrable after the “real” commit so that functional > > changes are not lost in the formatting. If the whole file is rather > > easy to adapt to the new style, the whole file can be changed, too. > > > > Thoughts, suggestions, opinions? > > While I can understand the thought behind not wanting to touch all the > code at once, I think it makes a transition messy and interminable. > Writing new code following a different guide makes both feel out of > place, and we don't have enough code modification going on to > organically make this transition. > > I would be up for, after pull requests that should be merged are merged, > automatically formatting the codebase to meet Google's Java style guide > with as much as it can without changing the bytecode. That way following > the style guide in new code won't feel as out of place, and anything > with annotate or bisect can be assured that the formatting commit did > not change functionality. >
We've been here and tried that previously... several things came out: 1) tools to re-indent existing code have bugs https://netbeans.org/bugzilla/show_bug.cgi?id=123258 (yeah, when you've been burnt by something you remember it ;)) 2) more tooling can help with addressing (1) ~ ofc that has been lost when we've migrated to git... https://emu.freenetproject.org/pipermail/devl/2007-December/027515.html 3) it will break git-blame. Apparently some people care... https://emu.freenetproject.org/pipermail/devl/2009-December/033809.html 4) it won't work unless you enforce it (CI tools come in handy there...) 5) The consensus last time we've done it was that the very first step is to commit the config file to make IDEs "do the right thing" going forward As for which coding style we go for, I don't care :) NextGen$
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
