I believe the consensus was to just use Lucene's style. In turn that looks like pretty much standard Java conventions, derived from Sun's original guidelines. In practice I periodically try to adjust the code base to match these guidelines on my own. Yes it would be nice to get everyone to check in cleaner code.
I personally favor 120 column lines, though I have seen religious wars fought over this. I suggest that the checkstyle plugin configuration should be considered the official version. If the Eclipse codestyle doesn't agree, I say change it to match. But I was seeing stuff like mixed use of tabs and spaces, missing braces, things like that -- on up to higher level things like unused imports, on up to even higher level issues (outside the scope of checkstyle) like using System.out and declaring constants as local variables. (Maybe I am mixing up the code you are working on with something else I 'fixed' though.) Sean On Tue, Dec 15, 2009 at 6:30 PM, Robin Anil <robin.a...@gmail.com> wrote: > I was writing this as a reply to Seans commit notice email and felt it > should be taken up with all the mahouters so as to reach a final > consensus. > > Few things i noticed > > I saw a new eclipse-codestyle.xml uploaded > http://wiki.apache.org/lucene-java/HowToContribute?action=AttachFile&do=view&target=Eclipse-Lucene-Codestyle.xml > > I saw a thread on hadoop list discussing about hadoop code style. Isnt > there a commonly agreed style for Apache java projects? > > Also hudson doesnt seem like it likes more than 80 char lines. I > thought that limit was just because old dot matrix printers couldn't > print more 80 chars. > > Similarly I setup checkstyle plugin on eclipse and it seems like the > above eclipse code formatting using the above code-style doesnt agree > with our checkstyle configuration. > > Add your thoughts and lets close this quickly > > Robin >
