On Sun, 2014-11-02 at 18:30 -0500, Juiceman wrote: > 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 :) > >
We did do all of the above... but failed at the enforcement phase; People use new and fancier IDEs and what was considered "best practice" coding-style wise 5y ago is not what steve is proposing. You're talking a lot about stuff that "can" be automated... are you volunteering? Last time I'm the one who did the automation; I'm not doing it again. 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
