Because of readability. So space is not wasted. And we do have more than 24 line to display, which is the old value, that caused people to compress code this way.
code formatting is a religious thing. i personally am not going to waste a whole line for one silly character, it’s bad enough my closing braces already do this.
to each is own
Wow :o. Then just write everything into one long line 
It is clear, that blank lines, separating logical blocks, improve visibility. And separating the method signature from the body by one line also does, never mind if there is an opening brace in it or not. Many people put a blank line after the signature, so why not use this to put the brace there and further improve visibility ???
Yes I know… it’s just religious. But then I’m a god’s man
Marvin
I’m religious too, but putting a new line for a bracket or not doesn’t really change visibility for me at all, but that’s me. my use of tabs makes it visible enough to find where the opening bracket began o_O;
Now here we go again… . ;D
Rafael
I may not have work on it, but I am learning ;D
Well acutally you can save the different code styles in Eclipse… and once you are done typing your code, you can just use eclipse Auto-Style key to make it in the style you want… ^^
Actually I think that’s a dangerous thing (we tried this at work, but reverted to semi-manual formatting), since one false setting will screw your Versioning history completely, leaving you with conflicts on every update.
I think the easiest sollution would be to adhere to the SUN coding style, where it makes sense and suites your needs, but allow for a bit looser convention where the religous feelings of a developer might be hurt ;). We do so at work and surprisingly our code is still readable despite of slightly different code-styles and everyone is happy.
Agreed.
And I repeat, Marvin, that it was stated clearly in the wiki that the code formatting conventions which should be followed for Xith core and toolkit code was Sun’s one…
A page has been added (by me) to precise some things : http://www.xith.org/pages/developers_infos.html
The page as a whole is really cool. But as you may expect I’m not totally happy with the phrasing of the coding guidelines part. In principle I could live with it. But if you’re receptive for a slightly different phrasing, I would like to tell you. But let’s do it by PM, ok?
Marvin
Hmm I could add “In specific cases when a specific formatting fits specificly well for a specific piece of code, you may be specificly allowed to violate a bit Sun’s conventions. But these cases have to remain exceptions”
You don’t have to be sarcastic :-.
I’ll send you my suggestion by PM. But I first need to do some other things. So in an hour maybe…
Marvin
Because of readability.
Did you try it yourself? For a few years?
I did. (As I already said I used 3 popular styles for a couple of years each.) And it really doesnt make any difference… after you’ve used one for a while. And (as I also already said) most java people are used to hugging brackets. So, thats the most readable (and writable) one for em (w/o any extra training).
I don’t consider Sun’s conventions as a good habit.
I do. And I think its awesome that Java has such a thing. Java code is much more consistant thanks to that. Its also great that there are guidelines for documentation.
At the end of the year you save countless hours thanks to that. (Seriously.)
I agree with Onyx.
Huh okay it was a bit sarcastic but the core message is here, isn’t it ?
Err in an hour time I’ll be in bed probably.
Well. I finished the work on the OBJLoader, which was an important task to do. Now I’ll write the suggestion text and send it to you. So if you have 10 minutes…
Marvin
Well okay.
it was a bit sarcastic
No, it wasnt. I just tried to be clear. 
And I do actually think those conventions (doc+code) are the biggest strength of java. It improves productivity like being memory managed does, but unlike that its not a given.
I was talking about what I said ;D
Well I agree totally but if you could only convince marvin…
disclaimer: I’m just another programmer who doesn’t contribute anything to xith.
from my work experience in tons of java projects (brackets at the same line) and .NET projects (brackets at the next line) …
it doesn’t matter one bit. Readability of bracketplacing is as measurable and objective as your personal experience of the color blue.
Personally I prefer brackets at the same line, but only because I’m used to it. Decide on a contract, interface, design etc and let the coder do his thing.
At work we let the editor’s "reformat’ options (eclipse & visual studio) decide.
Readability is very subjective and never really worth it to debate/enforce it beyond “good enough”.
I agree ;D
That was, IMHO, a pretty shocking abuse, but I’ve opened a thread on that in Off Topic, and won’t mention it again here.
You’ve completely missed the point if you think that is “a client’s job”: the whole idea is that irrespective of what the client sends to you, the server reformats it, deterministically, into a single internal style that is always, absolutely, consistent.
There is an active discussion on this on sweng-gamedev at the moment (google for it, its the nightrider server or whatever, can never remember the address off the top of my head).
Google for “tdd” and “graphics” or “opengl”. In essence, though, you generally write a “demo” for each feature that just shows it in a window. You also write a wrapper for any such demo that invokes the demo, then takes a screenshot, then compares that screenshot to an image file on disk, and if the two files differ then it is a failure. You can do “tolerant” comparison and store the file as e.g. a jpg to save space, or “tolerante” comparison on BMP (preferred way!) allowing you to allow for some small variation between different hardware.
A lot of discussions in games conferences and over the web point out the “isnt’ this going to take us AGES to setup?” but the majority of feedback from mainstream IT and paint-program vendors at conferences and in papers seems to be “actually, for 90% of the codebase, it really takes very little effort at all, so long as you write a wrapper to automatically take + compare screenshots - AND you get a demo for every single featuer of your engine/API for free!”. For the remaining 10%, some people chose to ignore them to save time, others pick and choose which particuarlly important / fragile tests to actually implement.
Bear in mind that this is VERY valuable for multi-author projects like Xith, because it protects you against accidentally reversing the texture co-ords or other such small yet important mistakes that Xith’s had before. None of them were major problems, but it just saves some extra time int he long run AND makes the project MUCH more attractive to commercial developers, knowing it has unit tests - and it will much more safely scale to extra developers contributing over time, because you dont have to worry about them breaking things accidentally.
I’m afraid that again you’ve missed the point. Hopefully the above explanation makes things clearer?
Actually, reading that thread, people have pointed out good reasons why this is a very bad idea (e.g. diffs going haywire). Further, most of us cannot work with a stupid code style, so will occasionally have to reformat to a “known” style to do any work - but how do you put the finished code back into the stupid style that it was in originally? You can’t - which is why server-side reformatting is so valuable.
FYI to Marvin: I actually totally agree that next-line for braces is the preferred way. Interestingly, the vast majority of professional java coders I interview also do this in all their source, my best guess for this being that most universities are choosing to teach next-line-braces (bearing in mind I interview a lot of java coders each year).
PS: I can actually provide - I think - scientific evidence that everyone else is wrong :P, but I fear they wouldn’t accept it and would be forced to kill me and burn the evidence (and find and assassinate the authors of the HCI reports I’d be using, and kill them too), and that’s too great a loss to mankind, so I’m not going to ;D. LOL.