Right, and Derby has not chosen either of those styles, the text is
correct in saying *individuals* have found those guides helpful.
Ah ok, so not that these are the only style guides that contributors
should follow, I should read more carefully
- also it's not good to have
unused imports kicking around, it adds bloat to the code, and it's
unnecessary, removing these wouldn't hurt regardless of the rest of the
changes.
Agree there, removing unused imports is a good thing to do. Though they
don't do any harm to the runtime footprint, only the .java file and
cause yellow flags in Eclipse.
This is one of my concerns, Eclipse has a pretty good warning system,
but if it's flooded with small silly warnings (things that should really
be fixed), then it's possible to miss out on the warning that's
important. At the moment there are 7000+ warnings (of all different
types) reported by Eclipse - how many of these are really important, I
don't know, but by getting rid of the easy ones it's easier to see the
important ones where perhaps the warning should be taken seriously or
perhaps not.
Also I'm suprised that there isn't a defined style (regardless of
whether I like it or not) - every single other open source project I've
worked on (Java, C, Ruby, whatever) has had a style that submitted
patches must conform to before they are considered for inclusion, and
it's a little odd that Derby doesn't have this.
It's because no one has had a stong itch to enforce a coding style, and
come up with the rules/process for accepting a patch or not (do we want
to turn away contributions due to a coding style issue, do the
committers want to spend their time checking coding standards). Any
experience you want to bring from other projects would be great here.
The only thing I would say here is that the projects I've worked on tend
to be upfront about the coding style which is being enforced (Ant is the
Sun coding conventions (roughly), Rails is 2 spaces, no tabs, Ruby style
for method names, Ruby is follow the current code etc), for code that is
already in svn/cvs, the most sensible thing would be to gradually change
it as a committer comes across it, or during refactoring etc.
As I mentioned before, it's better if there is an automated process to
check files so that it's not seen as a personal issue (which it isn't).
Jalopy, checkstyle, pmd are all good for checking Java and all can be
run as part of the build process (all have Ant tasks). If a style is
chosen, then supplying a template file for IDEA/Eclipse/vim/emacs would
also be of benefit as then the developers can code how they like and the
IDE can massage the code into "the one true style". An svn check in
script could also be used to fix up formatting before the commit takes
place.
Obviously as a newcomer I don't want to rock the boat, (and style/brace
wars are always nasty) - hope I didn't cause offense.
Kev
