Thanks for the perspective Hen. It sounds like good advice. I do think there would be a benefit to hitting control-f (ie. autoformat) once for the whole project; its pretty messy now. I'm completely agnostic to which code style we use. Perhaps Eclipse's autoformatter's default setting would be a pragmatic choice.
Charles Matthew On Fri, Sep 17, 2010 at 1:55 AM, Henri Yandell <flame...@gmail.com> wrote: > Not that I know - it's a classic way to start an argument :) > > General rules (of open source) are: > > * Adhere to the style of the file you're editing. > * Don't commit sweeping reformatting with any other modification. > * Don't impose your editor on others. > * Just do it; aka 'at the end of the day we're volunteers, and someone > who's prepared to do something generally has the moral advantage'. > > The main pain point I imagine are that if you do some work and hit > ctrl-f (or whatever it is; I've not used Eclipse/Intellij for a long > time :) ), and it reformats, then you need to load a clean version, > reformat and then commit so your work and the reformatting aren't all > mixed together. That's the main thing that will get tuts and > complaints. :) > > Hen > > On Mon, Sep 13, 2010 at 6:23 AM, Charles Matthew Chen > <charlesmc...@gmail.com> wrote: >> Great, Sebb. >> >> On a related note, I'm tempted to standardize the code formatting >> of the entire project using something like Eclipse's autoformat >> feature. Is there a preferred code standard for Apache code? Better >> yet, is there a pre-existing settings file for Eclipse's autoformat? >> >> Charles Matthew >> >> >> On Thu, Sep 9, 2010 at 10:30 PM, sebb <seb...@gmail.com> wrote: >>> On 9 September 2010 20:56, Charles Matthew Chen <charlesmc...@gmail.com> >>> wrote: >>>> Sebb, please feel free to clean up warnings, etc. in Sanselan. >>>> There's tons of code clean up that I'd like to do if I ever have time. >>> >>> OK, thanks. >>> >>> I've now fixed the more obvious warnings. >>> >>> There are still a lot of unthrown Exceptions, but as the remaining >>> ones are part of the public API I did not remove them yet. >>> We should either document them (which prevents the Eclipse warning) or >>> remove them, e.g. when 1.0 is released. >>> >>> Most of the code is infested with tabs (I'll start getting rid of the >>> ones in the test code first). >>> >>>> +1 to have more active committers on Sanselan. >>>> >>>> Charles Matthew >>>> >>>> >>>> On Wed, Sep 8, 2010 at 1:48 PM, Matt Benson <gudnabr...@gmail.com> wrote: >>>>> For my part, I should think the community would be glad for someone in >>>>> addition to Charles to have his hands in sanselan. >>>>> >>>>> -Matt >>>>> >>>>> On Sep 8, 2010, at 11:37 AM, sebb wrote: >>>>> >>>>>> There are quite a few Eclipse warnings in the Sanselan test code. >>>>>> >>>>>> For example, test cases that declare impossible Exceptions. >>>>>> Also potential null pointer exceptions that can be fixed either by: >>>>>> - changing assertTrue(null != value) to assertNotNull(value) >>>>>> - or by explicitly checking for null >>>>>> >>>>>> Any objections if I just fix these? >>>>>> >>>>>> Or should I create a JIRA with patches first? >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
