Java-Gaming.org    
Featured games (91)
games approved by the League of Dukes
Games in Showcase (576)
games submitted by our members
Games in WIP (498)
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  
  One common code style  (Read 7777 times)
0 Members and 1 Guest are viewing this topic.
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Posted 2006-10-31 19:52:39 »

As you may support, it is important to have/use one single common code style. This style should offer the best possible readability for all. So far some different code styles have been used in the xith codebase. I've been talking with Amos about that and so far he accepted all of my justified suggestions. I'll sum them up here and we can discuss about them. When the majority of everybody willing to contribute to Xith3D or Xith-TK agreed to them, we can introcuce them as the common coding guidelines.

  • Braces (putting the opening-brace at the beginning of the next line):
    The advantages of putting the opening-brace at the beginning of the next line is simple to descibe but very important:
    • It is much more structured, since you can easily see from position of the braces, where a block begins and where it ends (espeacially where it begins).
    • It forces you to leave a blank line between the signature and method body. Well, this is done anyway by most people. But why then not simply put the opening brace at the begining of the next line???
    • And it provides a better, nicer look of the coding, which is of course subjective.

    Putting the opening-brace at the end of the signature sometimes seems to me like the search for an answer for the question "Where to put this lazy opening-brace?". But putting it at the beginning of the next line is "using it as a tool for improving the code structure" as it is meant to be.

  • indentation:
    Indetation must start with zero, then all lines are to be indeted (hierarchically) by 4 spaces. This also means, that no tabs are to be used, since tabs are differently displayed in different environments. And of course the empty lines are to be indeted, too. This is nothing one will directly see, but it helps a lot when adding new lines next to these empty lines.

  • line wrapping:
    By standard Eclipse wraps lines at column 80, which is somewhat old, since we nowadays have larger resolutions and are not forced to work on a 80 columned DOS screen. The automatic line wrapping whould be switched off (set to a large value like 1024). If I ever want a line to be wrapped, I'll do it manually when I type the line. No need to wrap a line, if it has 81 columns.
    However JavaDoc comments should be wrapped by column 80, since it is readable block text, which provides a better readability if wrapped at column 80.

  • white spaces:
    The parameters of method calls should be spaced by one space after the opening bracket and one before the closing bracket like this:
1  
myMethod( arg0, arg1, arg2 );

I myself needed some time to acclimate with this, but at the end it again provides an even better readability. Well, if Eclipse is configured like this, it will produce code like this:
1  
myMethod( a( b( c( myFunction( p0, p2, p3 ) ) ) ), arg0, arg1, arg2 );

Which is a little bloated. So decide on your own, where to let eclipse format the code, and where you want to have it a little more campact. But at least when you have one braced arguments list, space it.

Return statements are to be spaced and braced, too, since it just fits into the whole system, as well as throw statements, even if Eclipse code formatter doesn't fully support it. Do it like this:
1  
2  
3  
4  
5  
6  
7  
8  
9  
public void myMethod1()
{
    throw( new IllegalArgumentException("bla") );
}

public String myMethod2()
{
    return( "bla" );
}
    [/li]
  • JavaDoc:
    Of course it is a good idea to always create JavaDoc tags, when you create a new class. Never commit an uncommented class. Try to use abstract texts, which say more than "Does XXX" for a doXXX() method, if it does more.

  • visibility:
    Try to give a class or method as less visibility as possible. This means, make a method private, if it is logically private (never used from outside). Keep in mind, that no-modifyer is not private! It is the same as protected, but is not visible in subclasses.

  • Make use of class hierarchy:
    If you want to use a Vector, HashMap, Point3f, etc., consider, if you need the additional methods the concrete class offers compared to an implemented interface like List, Map, Tuple3f. If you don't need them, just define the variable or (more importantly) the parameter as the interface type. This gives you the advantage, that you're free to choose the conrete class or in case of parameters gives the users the freedom to choose, which is a real big benefit.
    This is mostly already done and has less to do with code formatting, but I thought it would be good to list it here, too.

If I forgot anything, I'll edit this posting and add it.

I created an Eclipse code formatter export file. So you don't need to configure your Eclipse on your own. It would be very nice, if one of you NetBeans users could send me a file for NetBeans. I'll then attach the file to this posting, too. Don't know, if NetBeans even supports code formatting.

You can download the formatter export file from Xith3D Code conventions page.

Marvin
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #1 - Posted 2006-11-07 19:57:55 »

After nobody objected, please consider these code conventions as the official ones.

Marvin
Offline c_lilian

Senior Member


Projects: 1


Java games will probably rock someday...


« Reply #2 - Posted 2006-11-08 07:15:01 »

Marvin, are you aware that at least two rules are against the sun java style coding convention ? (braces and white spaces in method signatures)

http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html

I can't see why you want to use a style different from what everybody else does in thousands of project. For me, this would clearly be a show stopper for Xith, marked as "not professional" at first source code inspection.

sorry for beeing late, I forgot about this topic.

Lilian Smiley

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline cylab

JGO Knight


Medals: 34



« Reply #3 - Posted 2006-11-08 08:18:28 »

At least the opening brace code convention from sun is braindead. In fact all projects our company works on use the bracket-on-newline style. On the other hand we also prefer tabs over spaces for some reason.

I consider your post as positive provokation, since judging a project by code-style would be "upper-management-style" and regarding your posts you seem to really work for your living ;-)

Mathias - I Know What [you] Did Last Summer!
Offline c_lilian

Senior Member


Projects: 1


Java games will probably rock someday...


« Reply #4 - Posted 2006-11-08 08:41:34 »

hehe, I hope other users will reply now...

One thing for sure : I don't like opening braces on new lines : too much space taken on screen for something that doesn't carry any kind of information.
I also #Dont.like(_ these, white, spaces_) especially when using nested calls, but I could cope with it. 

Lilian Smiley

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #5 - Posted 2006-11-08 10:06:18 »

hehe, I hope other users will reply now...

One thing for sure : I don't like opening braces on new lines : too much space taken on screen for something that doesn't carry any kind of information.

Modern programming is not about reducing the size of the source, nor about conserving space on 20" ultra high resolution monitors (yours for just *a couple of hundred pounds* right now!) - it is generally accepted that code clarity and ease of maintenance are far more important, and we can currently display around 10 times as much text as we used to back when opening brace line compression was first mooted.

I'm not saying you're wrong, just pointing out that the compromise has to be made somewhere.

Also, my memory was that the official java code style used braces on new lines?

Quote
I also #Dont.like(_ these, white, spaces_) especially when using nested calls, but I could cope with it. 

IIRC this one comes from old word processors and source editors where ctrl-arrow combinations worked "better" with the whitespacing (or ... vice versa: they worked better with the other spacing, which is how the other spacing came to be used at all.

Can't remember the reasoning (makes little difference to me, I reformat the code "properly" before editing Wink) but IIRC the "correct" english-language spacing is generally believed to be easier to work with - probably because it *is* correct, english-language, spacing, and english is currently the dominant world language. Not a great reason, but anything that makes coding that little bit less stressful when I'm working at 4am for a 6am deadline is fine by me Smiley

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

JGO Coder


Medals: 1


http://t-machine.org


« Reply #6 - Posted 2006-11-08 10:07:11 »

Actually, ignore the english language spacing thing. I can't remember if it really is or not. Will edit post later with corrections when not rushing out of the house. Sorry.

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

Senior Member


Projects: 1


Java games will probably rock someday...


« Reply #7 - Posted 2006-11-08 10:44:48 »

hehe, I hope other users will reply now...

One thing for sure : I don't like opening braces on new lines : too much space taken on screen for something that doesn't carry any kind of information.

Modern programming is not about reducing the size of the source, nor about conserving space on 20" ultra high resolution monitors (yours for just *a couple of hundred pounds* right now!) - it is generally accepted that code clarity and ease of maintenance are far more important, and we can currently display around 10 times as much text as we used to back when opening brace line compression was first mooted.

I'm not saying you're wrong, just pointing out that the compromise has to be made somewhere.

Also, my memory was that the official java code style used braces on new lines?


FYI official java code style uses opening braces on same line than their corresponding block declaration.
 
I think braces on new lines are inelegant, certainly because i'm used to 9 years of not putting them there, but also as I said, they really don't carry information, so they don't deserve that special treatment.

a ';' after a code sentence (at the end of a line) doesn't convey much more information, and you wouldn't put it alone in the next line on your 20" monitor, wouldn't you ?


Lilian Smiley

Offline dsellars

Junior Member




Need to write more games


« Reply #8 - Posted 2006-11-08 11:44:12 »

it really is amazing how many time this argument comes up! Smiley

why can't people, especially on os projects, just look up the sun java recommendations and use those?  then everyone knows where they are?  They are even a easily selectable option in most ide's.

Dan (<-bemused)

Offline Amos Wenger

Senior Member




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


« Reply #9 - Posted 2006-11-08 16:58:33 »

it really is amazing how many time this argument comes up! Smiley

why can't people, especially on os projects, just look up the sun java recommendations and use those?  then everyone knows where they are?  They are even a easily selectable option in most ide's.
Yeah sure, that was Marvin idea.

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline c_lilian

Senior Member


Projects: 1


Java games will probably rock someday...


« Reply #10 - Posted 2006-11-08 17:31:36 »

And so is mine, check out the 'official' link I provided.

Lilian Smiley

p.s. don't take that topic too seriously Smiley  you and marvin are doing a great job these days on Xith. I hope I'll be able to contribute someday as much as you two.

Offline ryanm

Senior Member


Projects: 1


Used to be bleb


« Reply #11 - Posted 2006-11-08 17:41:53 »

I also think it's easiest just to use the Sun standard: Anyone quickly browsing through the source isn't going to be surprised by what they see, and anyone actually working on the code can do a quick esc, ctrl+f and have it how they want.

Formatting is not a big issue, it's more important to set rigid standards for method naming, javadoc and so on.

Incidentally, I thought the whole opening-brace-on-the-same-line thing just a wheeze to save on printing costs for K&R. It then got entrenched and java followed suit so as to ease transition. Or at least that's what I remember reading somewhere.
Offline hawkwind

Junior Member




Java games rock!


« Reply #12 - Posted 2006-11-08 17:53:52 »

I agree that formatting is less critical than API integrity...if most everyone is using Eclipse then lets use the default formatting .....
Offline kevglass

JGO Kernel


Medals: 85
Projects: 25


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #13 - Posted 2006-11-08 19:05:15 »

Always a fun heated discussion: http://en.wikipedia.org/wiki/Indent_style

Kev

Offline oNyx

JGO Coder


Medals: 1


pixels! :x


« Reply #14 - Posted 2006-11-08 20:21:02 »

I started with Whitesmiths style, years later I switched to BSD/Allman style (because it was way easier to use in some specific editor) and finally I switched to the K&R style.

Personally I think there isnt much of a difference, but I switched to K&R, because its the standard in java. So, its benefitical for all parties if I use it myself, too.

>english language spacing thing

Its not part of the language the spacing is standarized through ISO norms and its a printing thing. I pretty much only use spaces in method heads such as foo(int x, int y) and thats about it.

弾幕 ☆ @mahonnaiseblog
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #15 - Posted 2006-11-08 23:01:08 »

Marvin, are you aware that at least two rules are against the sun java style coding convention ? (braces and white spaces in method signatures)

I certainly am Wink. But at teast the one about braces is crappy. As I mentioned above, I can't see how this one made its way into any modern standard. Nowadays we aren't forced anymore to work on a 80x24 terminal. We have some space to spand on readability. Being objective nobody can deny, that putting BSD/Allman style is the best readable one (ignoring whet he is used to see). And putting some whitespaces after open bracket and before closing brackets in method calls just further supports/improves readability. Nevermind what Sun pronounced years ago. A modern standard (for modern displays) should look the way I described, shouldn't it?

I can't see why you want to use a style different from what everybody else does in thousands of project.

Everyone else Huh No. I believe, there are as many people putting the braces at the "right" position as ones putting it at the "wrong" place Wink.
There're valid aguments for all styles. But really think the one described above is the best for modern times. Not too many people will want to put code on a printer when we have enough memory to load an entire souce file (and more). As I sayed, nowadays we can spend more on readability. And readbility is absolutely improved by braces-at-the-next-line and widely degenerated by braces-at-the-same-line.

For me, this would clearly be a show stopper for Xith, marked as "not professional" at first source code inspection.

Well, every time I see code written in Sun's standard, I have a vision of a script kiddie writing the code without knowing what he is doing Grin. Don't feel offended. It's just a funny idea, I have to get rid of the anger I have with code less readable because of wrong brace placement Wink. -- Ah! forget that Wink. It sounds like I don't respect others skilledness. Which truely is not the case, be asured.

At the end the true quality of a piece of code cannot be taken from the formatting but from the content. But a good and most imprtantly a common formatting is very important for readability.

One thing for sure : I don't like opening braces on new lines : too much space taken on screen for something that doesn't carry any kind of information.
I also #Dont.like(_ these, white, spaces_) especially when using nested calls, but I could cope with it. 

Well, I wouldn't say it doesn't carry any information. It truely supports finding the beginning of a block. Certainly IDEs like Eclipse help you to even find a brace not at the same indention level. But even with such help it is way easier to find it, read and directly understand code (not only foreign code), when the opening brace is at the same intentation level as the closing one. And as I wrote above, a "blank" line after the method signature further improves readability. Many programmers do this anyway. The the brace is best fitted into this (free) place.

And please reread this about the white spaces:
  • white spaces:
    ...
    Well, if Eclipse is configured like this, it will produce code like this:
1  
myMethod( a( b( c( myFunction( p0, p2, p3 ) ) ) ), arg0, arg1, arg2 );

Which is a little bloated. So decide on your own, where to let eclipse format the code, and where you want to have it a little more compact. But at least when you have one braced arguments list, space it.

I think braces on new lines are inelegant, certainly because i'm used to 9 years of not putting them there, but also as I said, they really don't carry information, so they don't deserve that special treatment.

Well, it's just a question of how you define "inelegant". Viewing it from readability-point-of-view, then putting the brace at the same line is inelegant. Viewing it from ancient-80x24-terminal-times, then braces at the next line is inelegant. Other definitions are imaginable. So as a conclusion, nowadays the letter definition is the one fitting better for "inelegant".

a ';' after a code sentence (at the end of a line) doesn't convey much more information, and you wouldn't put it alone in the next line on your 20" monitor, wouldn't you ?

Oh dear, this is something completely different Smiley. The braces structure the code and semicola just mark the end of a statement. Usually this is the end of the line, so there's no discussion about that. And I've never seen a discussion nor somebody using it like this.

why can't people, especially on os projects, just look up the sun java recommendations and use those? ...

Simple reason: The braces part is ugly, crappy and antiquated.

... then everyone knows where they are?  They are even a easily selectable option in most ide's.

Luckily Eclipse supports to modify and export it. Then there can be a place where a "better one" can be found by everyone Wink. Like it is now for Xith.

I also think it's easiest just to use the Sun standard: Anyone quickly browsing through the source isn't going to be surprised by what they see, and anyone actually working on the code can do a quick esc, ctrl+f and have it how they want.

Well, when I press ctrl+f on some piece of code with an unmodified Eclipse formatter, I don't get what I want. It is even far away from waht I want. How can that be? Wink.

Formatting is not a big issue, it's more important to set rigid standards for method naming, javadoc and so on.

This certainly is as important as formatting. That's why I put some notes about that under the formatting things Wink.



I hope, I was able to clerify my intentions.

Marvin
Offline kevglass

JGO Kernel


Medals: 85
Projects: 25


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #16 - Posted 2006-11-08 23:31:15 »

Seems like you've just said:

"Yeah, there is a common standard, but I don't like, so Xith isn't using it."

Or not?

Kev

PS. Antiquated is putting braces on a seperate line, one justification I've heard for it at Lucent Technologies (where I first started working after uni) was to minise the number of changed lines in source control when updating a conditional statement.

PPS. A common coding standard really doesn't effect productivitiy very much. Any software engineer with an ounce of ability is going to be able to either, a) cope, adapt and just read the code, b) simply format it locally to the style they like. There are some rare cases  where a really bad coding convention may hinder development (see my previous comments on military standards) but rarely does enforcing that competent engineers comply to some arbitary set of conventions invented by one of their peers actually increase productivity.

PPPS. What does the PPP stand for on these things?

PPPPS. And how many cany you have? Smiley

Offline Orangy Tang

JGO Kernel


Medals: 51
Projects: 11


Monkey for a head


« Reply #17 - Posted 2006-11-09 00:10:07 »

Why exactly do you need a coding standard other than the standard Sun one? Other than the braces issue (which is a religious issue I'm not touching with a ten foot clown pole), I don't think I've seen anyone do things substantially different in Java code.

Compare and contrast to C/C++ where every man and dog has their own radically different style, and even the loosest Java code looks nice and consistant. Lips Sealed

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #18 - Posted 2006-11-09 00:52:04 »

Seems like you've just said:

"Yeah, there is a common standard, but I don't like, so Xith isn't using it."

Or not?

No. I think I sufficiently justified it with readability reasons, which is an important argument, isn't it?

Why exactly do you need a coding standard other than the standard Sun one? Other than the braces issue (which is a religious issue I'm not touching with a ten foot clown pole), I don't think I've seen anyone do things substantially different in Java code.

Readability Smiley. And it is not religious, but important Wink.

Marvin
Offline kevglass

JGO Kernel


Medals: 85
Projects: 25


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #19 - Posted 2006-11-09 01:13:35 »

Not really, you've stated your opinion - whether or not any of your conventions or the Sun one's aid readability is pretty subjective. It would seem at least 50% of views expressed so far favor just using the Sun standards. If it were me I'd focus on making the code understandable and correct rather than worrying about inventing new standards to be questioned and criticised.

However, since it appears you (and Amos) are the only ones doing any development on Xith these days (and with things like this I can't see it changing a great deal) I don't suppose it really matters too much. It's your guy's project so why even post it, just enforce.

Kev

Offline oNyx

JGO Coder


Medals: 1


pixels! :x


« Reply #20 - Posted 2006-11-09 01:18:40 »

>it is not religious

It is. All formatting styles offer some visible hooks, which can all be utilized equally well. I used those 3 popular ones and they all worked equally well... after using em for some time. So using K&R would be benefitical, because thats what most people here (or java programmers in general) are used to.

Using Sun's standard means that it you get readability, because people know what they have to look for. Its similar to usability in that regard... meeting expectations is the most important thing there is.

弾幕 ☆ @mahonnaiseblog
Offline ENC

Junior Member





« Reply #21 - Posted 2006-11-09 01:52:56 »

Well.. if you ask me... just use the default java code style in this forum...

many companies have different code styles it really depends...

so does not settle the argument? haha... Tongue
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #22 - Posted 2006-11-09 02:55:10 »

We will stay with the coding style I described at the beginning. But thanks for the arguments. Smiley

Marvin
Offline ENC

Junior Member





« Reply #23 - Posted 2006-11-09 04:37:50 »

but I know someone will bound to break it...  Tongue

Esp the first timers in this forum...  Grin
Offline cylab

JGO Knight


Medals: 34



« Reply #24 - Posted 2006-11-09 10:28:40 »

Formatting is not a big issue...

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

We will stay with the coding style I described at the beginning. But thanks for the arguments. Smiley

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

Mathias - I Know What [you] Did Last Summer!
Offline ENC

Junior Member





« Reply #25 - Posted 2006-11-09 10:54:42 »

hey that's a great idea! Marvin why dont you start the poll since you are the one who started all these "arguments"  Tongue

heys.. suggestions right?
Offline dsellars

Junior Member




Need to write more games


« Reply #26 - Posted 2006-11-09 11:00:36 »

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 Smiley

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

Senior Member




May the 4th, be with you...


« Reply #27 - Posted 2006-11-09 11:52:41 »

but I know someone will bound to break it...  Tongue

Then I'll correct it and submit to SVN Wink.

Formatting is not a big issue...

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


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.

We will stay with the coding style I described at the beginning. But thanks for the arguments. Smiley

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

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
Offline oNyx

JGO Coder


Medals: 1


pixels! :x


« Reply #28 - Posted 2006-11-09 12:33:01 »

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

弾幕 ☆ @mahonnaiseblog
Offline woogley
« Reply #29 - Posted 2006-11-09 13:17:45 »

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

xsi3rr4x (15 views)
2014-04-15 18:08:23

BurntPizza (14 views)
2014-04-15 03:46:01

UprightPath (27 views)
2014-04-14 17:39:50

UprightPath (12 views)
2014-04-14 17:35:47

Porlus (29 views)
2014-04-14 15:48:38

tom_mai78101 (51 views)
2014-04-10 04:04:31

BurntPizza (110 views)
2014-04-08 23:06:04

tom_mai78101 (211 views)
2014-04-05 13:34:39

trollwarrior1 (179 views)
2014-04-04 12:06:45

CJLetsGame (185 views)
2014-04-01 02:16:10
List of Learning Resources
by Longarmx
2014-04-08 03:14:44

Good Examples
by matheus23
2014-04-05 13:51:37

Good Examples
by Grunnt
2014-04-03 15:48:46

Good Examples
by Grunnt
2014-04-03 15:48:37

Good Examples
by matheus23
2014-04-01 18:40:51

Good Examples
by matheus23
2014-04-01 18:40:34

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:22:30

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:05:20
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!