Re: [freenet-dev] Coding Standard
On 11/02/2014 04:07 AM, David ‘Bombe’ Roden wrote: > On 02.11.2014, at 01:57, Juiceman wrote: > >> The tool I am using to convert all the source in a repository is >> Jindent which also has the option to sort classes and interfaces, >> etc. > > I’m pretty sure that “alphabetical” ordering is in the same league of > non-logical ordering as “chronological” is. Indeed, logical ordering is something we'll have to move towards manually, but having the formatting aspects of the style followed is a good start and can be done automatically. signature.asc Description: OpenPGP digital signature ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Coding Standard
On 11/03/2014 04:56 AM, Matthew Toseland wrote: > On 02/11/14 23:30, Juiceman wrote: >> On Sun, Nov 2, 2014 at 4:53 AM, Florent Daigniere >> wrote: >>> >>> 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. > Please publish scripts. Thanks. I've posted verify-formatting-only. [0] It isn't completely automatic, at least at the moment. I didn't see a way to disable debug information from the command line. There's javac.args in fred, but that's not built-in support. Turning off debug is necessary when comparing class files in this context due to line numbers differing. One can use this by: 1) set debug="off" in the javac invocation 2) build pre-merge; copy to pre-merge.jar 3) build post-merge; copy to post-merge.jar 4) run the script [0] https://github.com/freenet/scripts/blob/master/verify-formatting-only signature.asc Description: OpenPGP digital signature ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Coding Standard
On 03.11.2014, at 19:49, xor wrote: > > On Monday, November 03, 2014 07:30:07 PM xor wrote: >> On Sunday, November 02, 2014 10:53:22 AM Florent Daigniere wrote: >>> 3) it will break git-blame. Apparently some people care... >>> https://emu.freenetproject.org/pipermail/devl/2009-December/033809.html > Thought about it again: > "git bisect" might do the job. Yes, it will, and reformatting will not change the results of a bisect. Greetings, -- * David ‘Bombe’ Roden signature.asc Description: Message signed with OpenPGP using GPGMail ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Coding Standard
On Monday, November 03, 2014 07:30:07 PM xor wrote: > On Sunday, November 02, 2014 10:53:22 AM Florent Daigniere wrote: > > 3) it will break git-blame. Apparently some people care... > > https://emu.freenetproject.org/pipermail/devl/2009-December/033809.html > > This is actually a very good observation which I didn't notice yet. > > Git-blame is important because discovering the original commit message which > introduced a piece of code helps very much with understanding why the code > is like it is. Given that fred is said to not have much documentation, its > important to be able to at least discover the commit message. > > So I would say that we shouldn't do automated bulk reformatting of the code > until someone can show that and how git-blame can be used in a way which > ignores the reformatting-commits. > Ideas anyone? Thought about it again: "git bisect" might do the job. 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
Re: [freenet-dev] Coding Standard
On 03.11.2014, at 19:30, xor wrote: > On Sunday, November 02, 2014 10:53:22 AM Florent Daigniere wrote: >> 3) it will break git-blame. Apparently some people care... >> https://emu.freenetproject.org/pipermail/devl/2009-December/033809.html > This is actually a very good observation which I didn't notice yet. No, it is really not. Most pieces of code that you would want to know about why there were done this way have most probably already been touched multiple times by multiple people so git-blame can not help you, anyway. If you want to know why something was changed, locate the commit that really did it (using “git log -- ” or a GUI tool of your choice). This way you will usually have all necessary context, such as simultaneous changes to other files, preceeding and following commits, and of course the commit message. Greetings, -- * David ‘Bombe’ Roden signature.asc Description: Message signed with OpenPGP using GPGMail ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Coding Standard
On Sunday, November 02, 2014 10:53:22 AM Florent Daigniere wrote: > 3) it will break git-blame. Apparently some people care... > https://emu.freenetproject.org/pipermail/devl/2009-December/033809.html This is actually a very good observation which I didn't notice yet. Git-blame is important because discovering the original commit message which introduced a piece of code helps very much with understanding why the code is like it is. Given that fred is said to not have much documentation, its important to be able to at least discover the commit message. So I would say that we shouldn't do automated bulk reformatting of the code until someone can show that and how git-blame can be used in a way which ignores the reformatting-commits. Ideas anyone? 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
Re: [freenet-dev] Coding Standard
On 02/11/14 23:30, Juiceman wrote: > On Sun, Nov 2, 2014 at 4:53 AM, Florent Daigniere > wrote: >> >> 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. Please publish scripts. Thanks. signature.asc Description: OpenPGP digital signature ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Coding Standard
On Sun, 2014-11-02 at 18:30 -0500, Juiceman wrote: > On Sun, Nov 2, 2014 at 4:53 AM, Florent Daigniere > 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
Re: [freenet-dev] Coding Standard
On Sun, Nov 2, 2014 at 4:53 AM, Florent Daigniere 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
Re: [freenet-dev] Coding Standard
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
Re: [freenet-dev] Coding Standard
On 02.11.2014, at 01:50, Steve Dougherty wrote: > 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. Unfortunately, that is true. :/ > 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. I think there are quite some changes that can not be done automatically, such as grouping/ordering methods and fields, or adding comments for those empty catch blocks. Then there is also the issue of javadoc, which is missing in ~99% of the places it’s supposed to be. No tool can do that automatically, and for a single person to add all those is pretty much impossible; after all we are talking about ~1000 source files. I do understand the motivation behind getting it done as quickly as possible (and that sure is tempting) but I don’t think the result would be code that conforms to this particular style guide. Greetings, -- * David ‘Bombe’ Roden signature.asc Description: Message signed with OpenPGP using GPGMail ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Coding Standard
On 02.11.2014, at 01:57, Juiceman wrote: > The tool I am using to convert all the source in a repository is Jindent > which also has the option to sort classes and interfaces, etc. I’m pretty sure that “alphabetical” ordering is in the same league of non-logical ordering as “chronological” is. Greetings, -- * David ‘Bombe’ Roden signature.asc Description: Message signed with OpenPGP using GPGMail ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Coding Standard
It also looks like Google and Sun are mostly the same but designating 'Google' does give us one standard to reference which I like. That said, Google calls out 2 space indents. Makes it easier to format the code, but harder to read. Thoughts? On Sat, Nov 1, 2014 at 8:57 PM, Juiceman wrote: > The tool I am using to convert all the source in a repository is Jindent > which also has the option to sort classes and interfaces, etc. > > On Sat, Nov 1, 2014 at 7:00 PM, David ‘Bombe’ Roden < > bo...@pterodactylus.net> wrote: > >> Hi there, >> >> initiated by a change in a pull request[1] the issue of coding style (or >> coding standard) popped up, once again. Instead of inventing our own coding >> style I proposed on IRC that we used either SUN’s Code Conventions[2] or >> Google’s Java Style[3]. >> >> Now that I’ve looked for the URL I would like to retract my suggestion of >> SUN’s Code Conventions, those haven’t been updated since 1999… :) >> >> So, Google’s Java Style. It’s reasonable close to what we already employ, >> and formatters in the popular IDEs will probably have no bigger problem >> creating output that conforms to this style guide. >> >> However, adopting a new style guide creates an immediate problem: the >> existing code. Which probably has more different styles combined than the >> style guide has words. :) >> >> 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? >> >> >> Greetings, >> >> Bombe >> >> [1]: https://github.com/freenet/fred/pull/298/ >> [2]: http://www.oracle.com/technetwork/java/codeconvtoc-136057.html >> [3]: https://google-styleguide.googlecode.com/svn/trunk/javaguide.html >> >> >> ___ >> 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 > -- 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
Re: [freenet-dev] Coding Standard
The tool I am using to convert all the source in a repository is Jindent which also has the option to sort classes and interfaces, etc. On Sat, Nov 1, 2014 at 7:00 PM, David ‘Bombe’ Roden wrote: > Hi there, > > initiated by a change in a pull request[1] the issue of coding style (or > coding standard) popped up, once again. Instead of inventing our own coding > style I proposed on IRC that we used either SUN’s Code Conventions[2] or > Google’s Java Style[3]. > > Now that I’ve looked for the URL I would like to retract my suggestion of > SUN’s Code Conventions, those haven’t been updated since 1999… :) > > So, Google’s Java Style. It’s reasonable close to what we already employ, > and formatters in the popular IDEs will probably have no bigger problem > creating output that conforms to this style guide. > > However, adopting a new style guide creates an immediate problem: the > existing code. Which probably has more different styles combined than the > style guide has words. :) > > 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? > > > Greetings, > > Bombe > > [1]: https://github.com/freenet/fred/pull/298/ > [2]: http://www.oracle.com/technetwork/java/codeconvtoc-136057.html > [3]: https://google-styleguide.googlecode.com/svn/trunk/javaguide.html > > > ___ > 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
Re: [freenet-dev] Coding Standard
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. > Greetings, > > Bombe > > [1]: https://github.com/freenet/fred/pull/298/ > [2]: http://www.oracle.com/technetwork/java/codeconvtoc-136057.html > [3]: https://google-styleguide.googlecode.com/svn/trunk/javaguide.html signature.asc Description: OpenPGP digital signature ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
