@Marvin : When you asked me if it was a problem for me the brace-on-the-next-line thing I say it didn't seem to. But I guess "write once, read everywhere" is a good thingTM that's true that if there are Java standard coding conventions we should stick to it. And they are most clear to me (and I'm used to it, too). Too much people against you, sorry man. And just remember some months ago you ranted at Croft, these issues made him exit the toolkit, now his code (whatever formatting does it have) have much less visibility. At least we could have included .jar in the toolkit distribution. You can't change the code style now that you fighted with someone to keep it.. that's just not logical. And no you and me aren't the only ones to work on Xith, Yuri is too, bohdan sometimes, hawkwind's probably reading, so does others users, you alone can't enforce it and I (sigh) didn't reflected enough about his issue before. To me it's like standards java coding convention is "good enough" and has more pros than cons.

given the amount of regular submissions to Xith, you should be happy enough that someone actually submitted something.would you throw away homework someone did for you just because you don't like their penmanship?you spend too much time on things like these that don't actually matter much.... if at all.save your rough drafting skills for the actual project

well, are you CIA to know SVN traffic for Xith3D or what ? (cia.navx, of course.. ). Besides, I agree with you.

@Marvin : When you asked me if it was a problem for me the brace-on-the-next-line thing I say it didn't seem to. But I guess "write once, read everywhere" is a good thingTM that's true that if there are Java standard coding conventions we should stick to it. And they are most clear to me (and I'm used to it, too). Too much people against you, sorry man.

Well, I posted this thread to give everyone the chance to argument pro or contra. After nobody did, the thing was clear to me. I really made a lot of thoughts about that and I'm really convinced, I created a good and well readable coding guideline. You (everybody) can't first say nothing about it and then, when I started to convert, begin to argument against it.

And if people who never contributed to Xith are argumenting against it, it is not important for the vote. Sorry. I think the situation is balanced.

And just remember some months ago you ranted at Croft, these issues made him exit the toolkit, now his code (whatever formatting does it have) have much less visibility. At least we could have included .jar in the toolkit distribution. You can't change the code style now that you fighted with someone to keep it.. that's just not logical.

Please don't compare this with the croft-situation. It sounds like you want to blame me a bad guy trying to destroy the project and to disperse people from it. Of course this is not the case and I will assume that this was not your intend, old friend. My true intention is always to improve the project and its quality.

I never told croft, to stick to the standard java guidelines, but just to make his code more readable. I don't know why he didn't contribute for so long, but I think he's not totally gone. The last thing I heard of him was, that he wanted to create interfaces to make it easier to port his loader from Xith to Java3D and vise versa. When I last talked to croft (per PM), it was quite good cooperation, as far as my impression was.

And what do you mean by "At least we could have included .jar in the toolkit distribution."?

And no you and me aren't the only ones to work on Xith, Yuri is too, bohdan sometimes, hawkwind's probably reading, so does others users, you alone can't enforce it and I (sigh) didn't reflected enough about his issue before. To me it's like standards java coding convention is "good enough" and has more pros than cons.

In this thread I never said, that we're the only ones contributing to Xith. Don't know where you have that from

c_lilian, kevglass, cylab, you and me were the only ones argumenting in this thread, who actually contributed or are contributing to Xith. The opinions are balanced. And c_lilian and kevglass didn't contribute for a long time. Just as kevglass said... We should just do it. And since there wasn't any straight guideline before, I think it is valuable, that I created one, that I plan to apply stricktly to the project.

oh, and you two should really setup your own forum, on your own site. JGO is a great place to post your Xith news, but it is NOT a good place to post a Xith devlog. thanks.

Why is that? There is a Xith-section in JGO, so this should not be a problem. And if you are refering to the unread posts feature, the xith-related posts are not too much (as long as the "new topic" button is not used for every bug found ) And woogley I found your posts a little offending - but just a little (and maybe it's just me)

@marvin:I think the discussion is not so balanced as you see it. While I prefer the brace-on-new-line-style, I think Amos and the others are right to some degree, so let's stick to the sun style *sight*, just to not seem ignorant. It really doesn't matter as long as there is a common style at all.

OK, then let's not talk about a common coding style anymore and do it like we did before. It is ok for me now, that everybody can do it like he wants to. I think, I have a best readable coding just as all the others do. As long as it is readable in any way, it's ok.

So we can end this discussion at this point before it gets more offending.

OK, then let's not talk about a common coding style anymore and do it like we did before. It is ok for me now, that everybody can do it like he wants to. I think, I have a best readable coding just as all the others do. As long as it is readable in any way, it's ok.

So we can end this discussion at this point before it gets more offending.

Phheww thanks guy I really didn't see how we were gonna get out of here.

But just for your info there *WAS* a strict coding guideline for the core & toolkit, that was Java Standard Coding Convention. It was stated in the wiki-tiki, probably my fault if it's not on xith.org now (but it contains not that much dev info, that should be fixed). So sorry but that was there.

I didn't mean you wanted to destroy the project or whatever else, just that in my opinion Croft has asked his COLLADA loader to be removed from the toolkit because he wanted to stick to his coding guidelines (instead of those used in Xith3D, known as "Sun/Java Standard Coding Conventions"). That is no problem for me, it 's just that his work lost a lot of visibility, and that I think when we/I release a toolkit build we could/should (to be talked with him) include his built jars with his code in it.

But just for your info there *WAS* a strict coding guideline for the core & toolkit, that was Java Standard Coding Convention. It was stated in the wiki-tiki, probably my fault if it's not on xith.org now (but it contains not that much dev info, that should be fixed). So sorry but that was there.

Yes, I know there was such a guideline for the projects and I din't want to deny it. What I meant was, that not everybody (including you and me) didn't use it exactly. And as I said, now I think it's ok, as long as it keeps readable for everybody.

1. Absolute bog-standard convention in the games industry (and in all large-scale dev work I've done in mainstream IT industry) uses check-in hooks on the SCM. One of the common ones is "reformat source code". There is NEVER a reason for you to have "different formatting"-introduced diffs in an SCM: if your SCM is so rubbish that it doesn't support check-in hooks, you need to come into the 21st century and get a good one .

Note: the other really common check-in hook is "run unit tests", with a refusal to check-in code that fails any of the unit tests. Finding 0 unit tests is sometimes regarded as a failure in its own right, depends how draconian your producer and/or lead programmer is .

(almost every formatter that plugs in to eclipse and NB has a command-line version designed to be friendly with your SCM)

2. Code style *is* important on an OSS project because it is part of the training of newbie programmers who come to the project probably relatively inexperienced and unskilled, and who benefit from being forced into good conventions early on until they reach the point where they are experienced enough to make their own, informed, decisions on what style(s) to use. All good OSS projects have newbie programmers, this is not a bad thing, it's a good thing: shows that the project admins are friendly and welcoming, and that in return for their time and code the developers are getting something substantial back (training, effectively, even if it is largely self-taught).

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org