i was faster 
I don't know if I can trust thatā¦ you had an edit :-o
gerbildrop said:
Our general rule is that "if you break it you own it"...
Okay then....I now own all of jME!!! Bwahaha! :evil:
I just had to interject my diversion.....so what were we talking about again? :P
I think using the Sun convention makes sense. Eclipse comes with a built in Sun coding standards formatter. Just specify it in (Windows >> Preference >> Java >> Code Style >> Formatter). The one thing I think should be tweaked about it though is their use of mixed tabs and spaces for indentation.
What do people think about the old tabs versus spaces indentation debate? I'm firmly on the side of using spaces everywhere and never using tabs. For the sake of readability if you mix tabs and spaces and then try to look at it on anything else, like a wiki post or on web page. it looks like a complete mess.
The Sun Java coding convention doesn't specify whether to use tabs or "4 spaces" for indentation, but it does specify that a tab character must indent 8 spaces, and the standard unit for indentation is 4 spaces, so your forced to use spaces at least for the 4 indents.
Oracle Java Technologies | Oracle
Four spaces should be used as the unit of indentation. The exact construction of the indentation (spaces vs. tabs) is unspecified. Tabs must be set exactly every 8 spaces (not 4).
Haha I know this is so absurdly detailed and nit-picky, but you know how programmers can be about the little details, especially if it's to become a standard across an entire project.
Edit:
If you use eclipse and want to try out a code formatter following the Sun standards but using all spaces you can download it here:
http://daniels.douglas.googlepages.com/JmeJavaConventions.xml
Import it in Eclipse:
Windows >> Preference >> Java >> Code Style >> Formatter
Then you can select some (or all) of the text in a Java file and hit (CTRL+SHIFT+F), this will automatically format a Java file with your specified code formatter.
We use the Sun convention almost exclusively.
Our rule, at work, is no tabsā¦ all tabs are replaced by spaces.
4 spaces for indentation
max line width is 120
anything over 120 must be logically split to a new line
all newline splits line up under what they're supposed to (if they need to be split)
e.g.
public String getBob(String bob,
String bob2)
yeah i saw that rule, and i think it sucks. but in that case i would vote for spaces too(even if i think tabs rule when manouvering in the code)
I vote Sun with spaces.
it doesn't really matter that much if it's spaces or tabs or whatever. i dealt with a lot of code formats and after most of them are not that bad after you get used to them (except the hungarian notation). after all most of the ides can be configured to display the code as formatted even if it's formatted with both spaces and tabs. same thing for navigating trough the code: it doesn't really matter if it's spaces or tabs.
while i still hang on to my own preferences where i can (no tabs, only spaces, indentation of 2), i think it's more important that the formatting is consistent for a project, so just agree to use some defined formatting rule.
mr coder made it already clear that for proper formatting/reading source code, purchasing a widescreen is the first and most important step
so what do the other devs say: mojo, renanse, irrisor, froggy?
spaces or tabs does matter when it comes to versioning though, you don't want a diff on tabs->spaces conversions etc
usually you can make a check somewhere to ignore white spaces when diff-ing.
Whoa !!, this forum has increased in intensity over the last year! (very nice). Here comes a few points I think should be taken into account when deciding how to do this in JME.
I totally understand that we use different IDEs (and we should) this is exactly why a very strict coding convension is a good thing because of these points:
Oak said:
...I like tabs better in my own code, and spaces better in other ppls code...
i agree to your statements oak, but the one above confused me :)
The biggest problem with spaces and tabs is not the actual indentation, it is when someone tries to vertically align things for improved readability. This can really nice-up-the-code, until some other editor with different rendering of tabs/spaces displays the code.
I vote for code not even containing tabs!
do you mean like the compiler reporting tabs as syntax errors?
oh, what the hellā¦ let's ban all whitespace characters and line breaks from our code! }:-@
you can also stick to reformating only the code you write/changeā¦
do you mean like the compiler reporting tabs as syntax errors?
oh, what the hell... let's ban all whitespace characters and line breaks from our code!
I think checkstyle might be nice to run if you want the information, but I'd make it optional in the ant build. Forcing users to run that and then most likely ignoring the slew of errors/warnings it reports is just more useless information (unless of course you plan on doing something about it! In which case you can run it on your code or a subset of the project. I believe there are checkstyle plugins for eclipse and probably for other IDE's as well).
@Mr. Coder, your right, to get this started jME developers should start following a chosen coding/white space standard for future development, starting with formatting the files they change. That at least won't have as big an impact as doing a global formatting and losing all the CVS history, because of a whitespace change.
Does anyone know if there's anyway to setup CVS checkin script hooks that will automatically format the code in CVS, maybe there is but probably not available through the dev.java.net CVS access. Also I'm sure any code auto-formatting forced upon developers could cause major headaches if it screws up which it inevitably will.
jME is in no way "out of control" from lack of coding standards, in fact most of it feels pretty consistent, but if it's possible and easy to do it's usually a good idea to have coding and white space standards.
We actually use a common Eclipse format for jME which you can get here if interested:
http://www.renanse.com/jme/jme_eclipse_format.xml
It's basically Sun's spec with very slight changes, like having indents within the switch body.
in that case, perhaps we should run with that. how about putting that info somewhere, like: "sun's standard but with these changes: bla bla bla"
Cool, I think that settles it!
I imported it into eclipse, and I'll use that for any future code I do!
@Renanse, like you said the only change I can see is the indentation in the switch statements, which makes sense.