One common code style

Unfortunately it is, at least using CVS (don’t know about SVN), because you will get a lot of conflicts, if two people working with different autoformat-settings (been there :).

While I am on your side regarding the opening braces (sun standard tends to become unreadable IMHO), it might be a good idea to make a poll for people contributing to the xith codebase :wink:

hey that’s a great idea! Marvin why dont you start the poll since you are the one who started all these “arguments” :stuck_out_tongue:

heys… suggestions right?

I think this is basically what cylab just said but one argument against people just re-formatting as they fancy before making an edit is that it becomes a real pain to track what the actual change to a file was if you do a diff you end up with loads of changes. You end up having to check a file out change the formating and check it in and then make your change then the next person does the same, which is really horrible!

Best thing to do is to make a decision and stick to it. As cylab said a poll would be a good idea, from people that are actually contributing/have contributed to the project (so that rules me out :slight_smile: )

One thought that just occurred if you do choose something other than the sun standards it needs to be really really really easy for people to look up what the standards are (so not hidden in this forum or on an obscure web page, may be a text file in the project?), or they’ll just ignore them.

ah well I think I’ve said enough on this subject :slight_smile:

Then I’ll correct it and submit to SVN ;).

That’s why I created and offered the Eclipse formatter file. And you really shoudn’t do: checkout from SVN, autoformat, change, submit !!!
At least it should be: checkout from SVN, autoformat, change, autoformat with the official formatter, submit.
But there shouldn’t be a need to autoformat a file. I personally think, autoformatting is only needed (and I only need it), when I checnge / correct the formatting of an existing file.

Hmm… no. I don’t like polls in this way. It’s too easy for people to say just No. I object! to everything without giving good reasons. While I gave really good reasons for it. I think I have enough info to stick with the current decision.

Marvin

I personally think, autoformatting is only needed (and I only need it), when I checnge / correct the formatting of an existing file.

I always autoformat after each change… to ensure that I follow the standard.

Otherwise unrelated lines may show up in diffs, which just wastes time.

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

@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 ;D 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.

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

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.

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.”?

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.

To me it hasn’t.

Please let me proceed with the work I’ve already done.

Be asured, that I don’t want to offend or disperse anybody, just as I didn’t want to croft.

Marvin

Ok… I really had enough of this arguments. All of you are like going in circles? :-X

People who may not be contributing to Xith can always learn and then contribute to it. Stating that only those who are contributing should have the final say is stupid. :’(

Personally, I think this topic is really getting personal. Just think if this topic is brought up in the Newless Clubiess Section. It will be utter chaos.

this is an excellent example of micromanagement, and why it is pointless.

a project like Firefox has the need to enforce such things… not Xith.

you NEED code to come in, Marvin, so don’t add another hoop to jump through.

besides, aren’t you two the self-proclaimed code cleaners? clean the code to your liking and forget about stupid enforcements!

quite humorous, really.

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 :wink: (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.

Marvin

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.

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.

Marvin

Well yeah but if some code become really too hard to read (e.g. Croft’s military code) then the source may be separated but the compiled jars still distributed.

Agreed.

Thank goodness that all of this is over… ;D

I’m going to resurrect this because there are some easy fixes :slight_smile: :P.

  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)

  1. 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).

@ENC and blah
Please stop influencing a (maybe) fundamental discussion about a project you’ve never worked on and with which’s code you’ve never been confronted. Correct me if I’m wrong.