On Sun, Nov 2, 2014 at 4:53 AM, Florent Daigniere <nextg...@freenetproject.org> wrote: > 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 ;))
Steve is checking bytecode to make sure this doesn't happen. > > 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 I'm sure something can be set up. > > 3) it will break git-blame. Apparently some people care... > https://emu.freenetproject.org/pipermail/devl/2009-December/033809.html It will only affect git-blame the first time the codebase is converted. Going forward it should not be an issue. Oh look! 5 years ago we could have done this and every commit since then would be clean for git-blame. Actually we were using SVN then iirc. > > 4) it won't work unless you enforce it (CI tools come in handy there...) Again, this is something that can be automated. > > 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 > And how did that turn out? Oh, right - That is why we are having this conversation AGAIN 5 years later. > As for which coding style we go for, I don't care :) > > NextGen$ > > _______________________________________________ > Devl mailing list > Devl@freenetproject.org > https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl -- I may disagree with what you have to say, but I shall defend, to the death, your right to say it. - Voltaire Those who would give up Liberty, to purchase temporary Safety, deserve neither Liberty nor Safety. - Ben Franklin _______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
