Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (482)
Games in Android Showcase (110)
games submitted by our members
Games in WIP (550)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2
  ignore  |  Print  
  Quality Code  (Read 7115 times)
0 Members and 1 Guest are viewing this topic.
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Posted 2006-11-13 18:20:29 »

As I think closing subjects is not a good habit I'll quote the message I wanted to anwer to cause it's really interesting and I don't want to censor people (at least not blah^3)

Quote from: blahblahblah
I'm going to resurrect this because there are some easy fixes Smiley Tongue.
Thanks for sharing your knowledge.

Quote from: blahblahblah
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 Wink.

(almost every formatter that plugs in to eclipse and NB has a command-line version designed to be friendly with your SCM)
We use SVN (@ sourceforge.net) and it does support check-in hooks. It may be interesting to set up a formatting check-in... The code standard for Xith3D is Java Sun Standard Convention (and this time, a link : http://java.sun.com/docs/codeconv/). Do you know any formatter for SVN ? (I guess Eclipse's internal one doesn't run command line).

Quote from: blahblahblah
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 Smiley.
I wonder what unit tests could we do on rendering software... maybe getting some pixels color (or simply checking there is no exception thrown). But tell me, do sf.net servers have 3D hardware-accelerated graphic cards ? How could we run Java there.. ?

Quote from: blahblahblah
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).
I agree completely. And I repeat code conventions for Xith is Sun's one. Marvin, you can use your style for you game e.g. and if I ever write some code for it I will conform to it but I guess if I ever work on a Java project I'll have to follow Sun's conventions so good habits first.

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #1 - Posted 2006-11-13 19:11:12 »

As I think closing subjects is not a good habit I'll quote the message I wanted to anwer to cause it's really interesting and I don't want to censor people (at least not blah^3)

I closed the topic becouse it was talked about enough and everyone seemed to be happy to not talk about it anymore.

Quote from: blahblahblah
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 Wink.

(almost every formatter that plugs in to eclipse and NB has a command-line version designed to be friendly with your SCM)
We use SVN (@ sourceforge.net) and it does support check-in hooks. It may be interesting to set up a formatting check-in... The code standard for Xith3D is Java Sun Standard Convention (and this time, a link : http://java.sun.com/docs/codeconv/). Do you know any formatter for SVN ? (I guess Eclipse's internal one doesn't run command line).

I guess this isn't a server job but a client's one, but I don't know. So Eclipse was the one to do.

Quote from: blahblahblah
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 Smiley.
I wonder what unit tests could we do on rendering software... maybe getting some pixels color (or simply checking there is no exception thrown). But tell me, do sf.net servers have 3D hardware-accelerated graphic cards ? How could we run Java there.. ?

It will also certainly be a client's job.

Quote from: blahblahblah
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).
I agree completely. And I repeat code conventions for Xith is Sun's one. Marvin, you can use your style for you game e.g. and if I ever write some code for it I will conform to it but I guess if I ever work on a Java project I'll have to follow Sun's conventions so good habits first.

Well, as a result of the whole discussion, I disagree, that Xith's conventions are Sun's ones. I thought we agreed, that everyone can have his own style as long as it is readable. Just as it was usus before.

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.

I totally agree, that a common coding style is important. But I made this thread to discuss about it, nobody objected and I made "nails with heads". And after it some pople came around to start the discussion. This cannot be. As far as I see it, the decision was made. And you cannot see the discussion imbalanced in preference of same-line-style, if mostly people having nothing to do with xith development argumenting against next-line-style.

So ignoring these people I voted next-line, cylab did. You had agreed to it previously, but switched during the discussion. kev-glass agrumented same-line, but told me to not ask, just do, because he is not developing xith anymore. c_lilian voted same-line.

So the discussion is about balanced. And so you cannot come around and pronounce Sun's style to be the one to be used, when the discussion does not clearly show this result.

Grabbing the conclusion of the last posts I repeat, that it is ok, if we grant people the right to use an own style as long as it's readable. But one should either prefer to use Sun's convention or mine.

Is this ok for you?

Marvin
Offline woogley
« Reply #2 - Posted 2006-11-13 19:24:56 »

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.

I disagree. modern-day displays have increased more in width than they have in height (hence widescreen LCDs), so why waste vertical space for 1 measly character when you can tack it onto the extended horizontal space?
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #3 - Posted 2006-11-13 19:35:40 »

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.

I disagree. modern-day displays have increased more in width than they have in height (hence widescreen LCDs), so why waste vertical space for 1 measly character when you can tack it onto the extended horizontal space?

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.
Offline woogley
« Reply #4 - Posted 2006-11-13 20:04:48 »

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
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #5 - Posted 2006-11-13 21:09:12 »

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 Shocked. Then just write everything into one long line Wink

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 Huh

Yes I know... it's just religious. But then I'm a god's man Wink

Marvin
Offline woogley
« Reply #6 - Posted 2006-11-13 21:15:41 »

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;
Offline rafa_es

Junior Member





« Reply #7 - Posted 2006-11-13 21:17:03 »

Now here we go again.. .  Grin

Rafael
Offline ENC

Junior Member





« Reply #8 - Posted 2006-11-14 01:45:15 »

Quote from: Marvin Fröhlich link=topic=15234.msg121891#msg121891
@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.

I may not have work on it, but I am learning  Grin


Wow Shocked. Then just write everything into one long line Wink

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 Huh

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... ^^
Offline cylab

JGO Ninja


Medals: 43



« Reply #9 - Posted 2006-11-14 09:09:17 »

Quote from: blahblahblah
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 Wink.

(almost every formatter that plugs in to eclipse and NB has a command-line version designed to be friendly with your SCM)
We use SVN (@ sourceforge.net) and it does support check-in hooks. It may be interesting to set up a formatting check-in... The code standard for Xith3D is Java Sun Standard Convention (and this time, a link : http://java.sun.com/docs/codeconv/). Do you know any formatter for SVN ? (I guess Eclipse's internal one doesn't run command line).

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 Wink. We do so at work and surprisingly our code is still readable despite of slightly different code-styles and everyone is happy.

Mathias - I Know What [you] Did Last Summer!
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #10 - Posted 2006-11-14 18:31:29 »

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 Wink. 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


"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #11 - Posted 2006-11-14 21:01:57 »

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 Wink. 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
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #12 - Posted 2006-11-14 22:43:57 »

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"

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #13 - Posted 2006-11-14 22:47:55 »

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 Undecided.

I'll send you my suggestion by PM. But I first need to do some other things. So in an hour maybe...

Marvin
Offline oNyx

JGO Coder


Medals: 2


pixels! :x


« Reply #14 - Posted 2006-11-14 23:05:33 »

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

弾幕 ☆ @mahonnaiseblog
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #15 - Posted 2006-11-14 23:12:19 »

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.

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #16 - Posted 2006-11-14 23:16:19 »

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
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #17 - Posted 2006-11-14 23:26:28 »

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...
Well okay.

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline oNyx

JGO Coder


Medals: 2


pixels! :x


« Reply #18 - Posted 2006-11-15 00:07:43 »

>it was a bit sarcastic

No, it wasnt. I just tried to be clear. Smiley

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.

弾幕 ☆ @mahonnaiseblog
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #19 - Posted 2006-11-15 00:11:25 »

>it was a bit sarcastic

No, it wasnt. I just tried to be clear. Smiley
I was talking about what I said  Grin

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.
Well I agree totally but if you could only convince marvin..

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline tusaki

Junior Member


Medals: 1


In a mad world only the mad are sane.


« Reply #20 - Posted 2006-11-15 15:05:51 »

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".
Offline ENC

Junior Member





« Reply #21 - Posted 2006-11-16 07:52:56 »

Readability is very subjective and never really worth it to debate/enforce it beyond "good enough".

I agree  Grin
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #22 - Posted 2006-11-16 13:58:24 »

As I think closing subjects is not a good habit I'll quote the message I wanted to anwer to cause it's really interesting and I don't want to censor people (at least not blah^3)

I closed the topic becouse it was talked about enough and everyone seemed to be happy to not talk about it anymore.

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.

Quote
Quote from: blahblahblah
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
We use SVN (@ sourceforge.net) and it does support check-in hooks. It may be interesting to set up a formatting check-in... The code standard for Xith3D is Java Sun Standard Convention (and this time, a link : http://java.sun.com/docs/codeconv/). Do you know any formatter for SVN ? (I guess Eclipse's internal one doesn't run command line).

I guess this isn't a server job but a client's one, but I don't know. So Eclipse was the one to do.

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.

Quote
Quote from: blahblahblah
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 Smiley.
I wonder what unit tests could we do on rendering software... maybe getting some pixels color (or simply checking there is no exception thrown). But tell me, do sf.net servers have 3D hardware-accelerated graphic cards ? How could we run Java there.. ?

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.

Quote
It will also certainly be a client's job.

I'm afraid that again you've missed the point. Hopefully the above explanation makes things clearer?

Quote
Quote from: blahblahblah
2. Code style *is* important on an OSS project because it is part of the training of newbie programmers /quote]
I agree completely. And I repeat code conventions for Xith is Sun's one. Marvin, you can use your style for you game e.g. and if I ever write some code for it I will conform to it but I guess if I ever work on a Java project I'll have to follow Sun's conventions so good habits first.

Well, as a result of the whole discussion, I disagree, that Xith's conventions are Sun's ones. I thought we agreed, that everyone can have his own style as long as it is readable. Just as it was usus before.

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 Tongue, 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 Grin. LOL.

malloc will be first against the wall when the revolution comes...
Offline whome

Junior Member




Carte Noir Java


« Reply #23 - Posted 2006-11-16 14:30:42 »

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.

(ps: I prefer brackets in same-line coding :-)
Offline cylab

JGO Ninja


Medals: 43



« Reply #24 - Posted 2006-11-16 14:54:07 »

Quote
You can't - which is why server-side reformatting is so valuable.

I am a bit afraid of server side reformatting, since I think whole file reformatting is evil per se Wink 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  Cool 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  Tongue

Mathias - I Know What [you] Did Last Summer!
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #25 - Posted 2006-11-16 19:58:54 »

Readability is very subjective and never really worth it to debate/enforce it beyond "good enough".

I agree  Grin

I don't think this was ever in question. So I agree, too.

I guess this isn't a server job but a client's one, but I don't know. So Eclipse was the one to do.

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.

Sorry. I just didn't know, but was assuming that it worked this way. So, thanks for your teaching Smiley.

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.

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.

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 Tongue, 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 Grin. LOL.

Good to hear that. Thanks for the info Smiley. It just supports my statement, that the next-line-style is not so unusual and that there's a good reason to use it Smiley.

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".

This is exactly, what I've ever done and which I really think is a good habit.

Quote
You can't - which is why server-side reformatting is so valuable.

I am a bit afraid of server side reformatting, since I think whole file reformatting is evil per se Wink 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  Cool 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  Tongue

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 Wink. (And nobody ever complained the style I added to someone's classes, since it was the same).

Marvin
Offline DzzD
« Reply #26 - Posted 2006-11-16 23:03:31 »

long time with no post so...

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.

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

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
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);
 }
}




EDIT: oups...

Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #27 - Posted 2006-11-16 23:23:13 »

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

Hmm... Never thought it this way, but you're absolutely right. It's pure logic. Smiley

EDIT: oups...

Huh

Marvin
Offline DzzD
« Reply #28 - Posted 2006-11-16 23:25:58 »


I wrote int x=0.0; and i didn't want to explain the edit  ... that's not logic   Wink

Offline cylab

JGO Ninja


Medals: 43



« Reply #29 - Posted 2006-11-16 23:50:48 »

brackets are also usefull without if/else/while etc.. statements.

Indeed. I got pretty used to write
1  
2  
3  
4  
5  
6  
7  
        gl.glBegin(GL.GL_TRIANGLES);
        {
            gl.glVertex3f(1, 0, 0);
            gl.glVertex3f(0, 1, 0);
            gl.glVertex3f(0, 0, 1);
        }
        gl.glEnd();


or in combination with labels to flatten if/else nesting
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
        computation:
        {
            if(skipComputation)
                break computation;
           
            // do some stuff
           
            if(computationComplete)
                break computation;
           
            // do some other stuff
       }


(And no, this is not some kind of goto! Wink)

Mathias - I Know What [you] Did Last Summer!
Pages: [1] 2
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

CopyableCougar4 (14 views)
2014-08-22 19:31:30

atombrot (28 views)
2014-08-19 09:29:53

Tekkerue (25 views)
2014-08-16 06:45:27

Tekkerue (23 views)
2014-08-16 06:22:17

Tekkerue (15 views)
2014-08-16 06:20:21

Tekkerue (22 views)
2014-08-16 06:12:11

Rayexar (61 views)
2014-08-11 02:49:23

BurntPizza (39 views)
2014-08-09 21:09:32

BurntPizza (31 views)
2014-08-08 02:01:56

Norakomi (37 views)
2014-08-06 19:49:38
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
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
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!