For some time we have had our own jMonkeyEngine repository (because we did not have write-permission to dev.java.net, and CVS is too slow to work with diffs). Now I am trying to merge our changes with the changes that has occured since we "branched" out. This is not very easy, because even though I tell diff to ignore whitespaces, line-endings, etc. the diffs become huge. This is my own fault, since I at some point got annoyed with jme-source coding having both tabs, spaces, and inconsistant code-style in general, and ran the VERY NICE "format" tool in eclipse.
Could anyone send me a link to an "eclipse-format-file" where the source-format settings for jME has been set ? If no such thing exist, may I suggest that the one is created, and that all source-code MUST be beautyfied/formatted before commiting to CVS. This will make it possible for anyone to work with JME in their own prefered source-formatting, and it will avoid all the annoyance with mixed tabs/spaces.
since some of us work in other IDE:s like IntelliJ IDEA, i don't agree on using such a format file, but I agree on putting down code formatting rules down to such a detail level that versioning doesnt go havoc like that. we have rules for that at jadestone and it works pretty good after people have modified their IDE:s beautifiers to conform as much as possible to those rules…
another thing to discuss is if we would want to run such a beautifier on the whole jME source, and sort of lose the history 
but it would be a great thing to do upon moving to a new versioning system, or perhaps when releasing a 1.0 to get a fresh start?
I concur. 
it shouldn't be hard to export the code formatter setting from eclipse and add them to the cvs (it's only a xml file).
i suppose it same easy to do for intellij and netbeans.
you'll just have to agree on a format though.
after checking with our CTO it seems we have chosen to go with Sun's code conventions all the way. Well defined, well known and in my own opinion a good standard.
http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html
Does anyone have any issues with that convention? mojo, renanse, devs?
the only thing i don't really like about the sun conventions is that they use 4 spaces for indentation. i prefer 2 spaces, for avoiding the code to be pushed to far to the right.
buy a bigger screen :lol:
i think we should go for tabs only, and tabs set to 4…
can't afford to buy a wider screen. 19" will have to be enough.
why are you such a big fan of wide tabs? 
widescreen man, widescreen!
i think it's easier to read, but most of all, if it's not critical, it's better not to add exceptions to a standard
i still can configured my ide to display the tabs at a width of 2. that would only affect the way i see it
oh, and you can't do anything to stop me 
i won't buy a widescreen just to fill it with tabs! doh!
or you could put your monitor at a high viewing angle to simulate smaller tabs!
i bet you set your tabs width to 16, just to be to point out how cool your widescreen is.
Bet my screen is wider than yours
Oh wait, it's turned in to a measuring contest
Intellij doesn't have a format exporter… We have to manually set our conventions. There are some things that come standard. I think that the easiest way we've found to stay in step with each other is to use checkstyle… the issue here (at my work) is that we have a lot of legacy code that can't go through checkstyle… it would take far more man hours to reformat and correct it.
Our general rule is that "if you break it you own it" if you write the code, then ensure it meets the standards (from our architecture team) if you've made changes to code you can check those in w/o a problem, however, if you make formatting changes to existing code, then those have to be checked in separately… this gives us at least a small basis to see the diffs. This also goes for refactored stuff as well.
I prefer 4 spaces, no tabs… but I also have a 120 width… if the code goes beyond that, then there are specific places that it's split to another line.
my 1/2 shekel
checkstyle is nice. it can even check if the GPL header is there.
Hello All:
An ant script could be created to check the format of the code for the project. Although it won't correct any error, it will highlight those lines in each file that diverges from the established conventions. This way it would still be IDE independent and reinforce any specific IDE code format configuration.
William
are you offering yourself for writing the script and working your way trough the output?
I am not an expert on ant, but I can take a look and see how far I can go
better wait a bit and see what the devs/others say.
edit:
btw, checkstyle includes an ant task: http://checkstyle.sourceforge.net/
http://checkstyle.sourceforge.net/anttask.html
We use checkstyle in our ant tasks (for some of our code projects), in addition to the normal operations (compiling and jarring) as well as running our test cases.
have fun! 