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”.
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.
Once I participated a opensource project where bracket-standard was:
“Keep bracket-style as the original file creator did it. You can use either same-line or next-line as you please if you are the one to create a new source file”.
Then more or less it was a common practise if somene derived an official maintenance responsibility to an existing module, he/she was granted to reformat brackets. Everyone was happy.
I am a bit afraid of server side reformatting, since I think whole file reformatting is evil per se Just reformat the block you are currently working on, if you really have to. I think going with the good enough rule is perfectly… well… good enough 8) As long as nobody starts to write lower case classes or converts all methods to Method-objects dynamically created in the constructor and attached to public properties, everyone will be fine
I don’t think this was ever in question. So I agree, too.
Sorry. I just didn’t know, but was assuming that it worked this way. So, thanks for your teaching :).
Well, I find it hard to work with the same-line-style, too. But I have and will always write additions in the style found in a class, never mind which good or bad or stupid style it is.
Good to hear that. Thanks for the info :). It just supports my statement, that the next-line-style is not so unusual and that there’s a good reason to use it :).
This is exactly, what I’ve ever done and which I really think is a good habit.
I totally agree… except, that I think it is a really bad idea to have mutiple styles over one class. So just write your additional code in the style you fond in a class. I know sometimes this is hard, but it worked for me ;). (And nobody ever complained the style I added to someone’s classes, since it was the same).
[quote]I don’t consider Sun’s conventions as a good habit. I repeat, that the opening-brace-at-same-line is not best for today’s displays. So brace-at-next-line is in any way the better one nowadays. Many people may have got used to the “old” style, but apart from that I like it next-line, being objective, next-line is the better one today.
[/quote]
I just want to say that i agree for the bracket part of this text. for me brackets at end of line have no sens. it is not logical for me to put brackets at the end of line cause i dont put single instruction at end of line for if/while/etc… and brackets only exist to make multiple instructions look like only one.
`if (condition)
do something
if(a==b)
System.out.println("…");
if(a==b)
{
System.out.println("…");
}`
brackets are also usefull without if/else/while etc… statements. They can be used to use same name of var with different type:
brackets have nothing to do with if/else/while and other statements in any language, so i dont understand why it seems so logical to open bracket at end of line
public void myMethod()
{
{
double x=0.0;
double y=0.3;
System.out.println(x*y);
}
{
int x=0;
int y=3;
System.out.println(x*y);
}
}
formatting should become ambiguous as formatting is mearly presentation.
formatting your code doesn’t influence how the code works. ppl should be allowed to use what ever ugly(yes ugly only my formatting is the right one!) formatting they want.
[client[Merged]] --> (re-)formatting (using server style) --> [server/repository]
appearandly theres are checking-in hooks, if there are check-out hooks then we can implent this and client with check-out hooks can use w/e they want in there only formatting world. Lets call it format-round tripping, if that makes it clearer. And since we work at the same level of abstraction the con’s of the other/normal ‘round tripping’ are absent.
although it is useless in the light of the above, I’d like to know that my preference goes to sticking the { at the end. And no I don’t do it to save lines, I do it because it’s easier to reconise indents and use indents to reconise structure, then it is to actually read anything. And it’s inconsistend or do you also write
check out hook will eliminate diffs.
formatting1 -> conversion on check in --> formatting2[server]
since everything thats checked in at the server is in formatting2 it will not cause diff’s on the server
formatting2[server] --> conversion on check out --> formatting1
since everything thats checked out at the client is in formatting1 it will not cause diff’s on the client
diff’s will occour wenn it’s only formatted one way, not wenn it’s two/both ways.
perhaps a more programmer like abstract example will work.
say at the server I’m using 10 digit system.
Theres a 4 on the server.
The client attemps to check the 4 out
the check-out hook is run and the 4 is converted into a 2 digit system resulting into 100
The client then checks in the 100
the check-in hook is run converting it to a 4
4 is compaired to the excisting 4 causing no diff (4 eq 4) <-> true
if the client checks it out again it converts it back to 2 digit system resulting into 100
again it’s the same as the excisting is 100 and the server returns 100.
some clairifications:
the check-out hook is not at the server but at the client.
code formatting conversion doesn’t require knowlage on the excisting code formatting. (as opposed to the example where 100 could be interpered as a 100 (10system) as well as 4(2digit) as long as the code is syntaxly correct there are no problems but since there are undoubtly also check-in hooks that could check the syntax it shouldn’t cause problems.
Yeah but you can see how many people have come on the xith3d boards because of that… okay I’m not an ad-master but I find interesting to harvest others’ knowledge.
It’s not like they come to the ‘Xith board’, they just click ‘show unread posts’, so you’ll probably
never see them again around here, some may not even have noticed they are posting on a Xith board.
Finally, would you really want to have all those visitors, on your Xith board that do not chat about Xith
but something that is a matter of taste? Nobody will change their taste because of this whole thread.
My final words here… or I’d be joining this time-wasting effort
[quote]It’s not like they come to the ‘Xith board’, they just click ‘show unread posts’, so you’ll probably
never see them again around here, some may not even have noticed they are posting on a Xith board.
[/quote]
absolutly true for me… never seen that was xith thread and I just clicked “unread post”…
to me they define why the block is there in the first place.
public realyRealyRealyRealyRealyRealyRealyRealyRealyRealyRealyRealyRealyLongNaaaaammmee = new Object();
{
doSomething();
}
is the same in both formattings.
ppl who use the new line for { have to check the end for a ‘;’ , ppl using the at the end of line { could have savely presumed a simple code block
if else etc and even ‘nothing’ saids something about the code block namely wenn it execute or what is defined in the block. even the absance of anything describes something about the code block.
I wouldn’t care about if brackets have nothing or something to do with other statements I care about that those statements have somethign to do with the brackets.
“The more brackets you go into the less interesting it gets.”
I don’t have a vote on this and I shouldn’t anyways, does that mean I shouldn’t share insigths. I like to be proven wrong or tested on anything I do, as it improves me.
I better get back to work, I have to catch up on all those lost lines of code
Just reformat the block you are currently working on, if you really have to. I think going with the good enough rule is perfectly… well… good enough 8) As long as nobody starts to write lower case classes or converts all methods to Method-objects dynamically created in the constructor and attached to public properties, everyone will be fine 
