No… if you deliver this kind of code at a software company, you get your ass handed to ya
this is just gargabe
functional code is nothing compared to structure and comment
[quote]Programs are written so that people can understand them
[/quote]
If I would write this kind of code at my university, I would, even if everthing works, get 0 points…
Funny you can say this without giving any examples. This is nothing more than a load of bullshit.
Look people are just trying to help.
They are right, the code has horrible structure and no JavaDoc/comments. If you want people to help you work on this then that’s something you need to accept and fix.
I don’t understand why he needs to give you examples… Just look at someone else’s work and you will see.
I’m willing to help if you want to know what areas need to be changed, if you don’t want to go read books about this.
there is a reason why your game is running so slow also =)
it all comes down to bad software architecture and code design
the bullets seem to miss the correct direction towards the mouse position. I think it’s because the mouse coordinates start from the very left upper corner of window but drawing coordinates start from where u paint your graphics. So you probably need to subtract from mouse y like -14 or something before you pass it to calculations
The structure is fine, and no comments doesn’t automatically make code bad. It’s not helping to just say something sucks. You need to provide examples.
Edit: This kind of shit is making me not want to open source anymore.
I didn’t say you code ‘sucks’, I’m just trying to help.
I won’t give examples, that you can look up. But say a few basic things that will help you improve your code.
-Public fields are a no no. You needs to make sure everything is encapsulated. So make all fields private and only use methods to access them.
-Spilt the classes in separate files.
-Class name first letter starts as a capital.
-A method should only have one function, not doing many things at once.
… and its late here, so someone else can take over.
It’s true, the structure is fine and no comments doesn’t make it bad, FOR YOU. It’s your code so it’s sure that you can understand it very easily.
While you still have structure, it might not be the same structure as the structure people are used to, so they consider that this is a bad code. If you want to be able to work in a group, you got to use the structure that is normally use because it’s what most people are used to and it’s hard to get used to a new structure. So most people will consider it a waste of time to work with someone else who code completely differently than they are.
Alright, I’ll agree to that. But Cero is saying my code is bad, and my game is running baddly because I don’t have comments or capitalisation. Once I finish a project I go through and clean up it’s code. This code is “sloppy” (I.E. lacking in minor manners) because the game isn’t done yet.
Thank you. The thing is that no one is giving an example of what “normal structure” is and why mine is “abnormal.” I agree that the no comments thing is bad, but really I’d just be adding things like “//this is the paint method. It paints the screen” I don’t know what NEEDS to be commented, as I was never very good at explaining my code.
I think you’re taking our critisism the wrong way.
Don’t forget there are a lot of experienced people lurking around these forums, and the last thing they want to do is to annoy new folks, and at the same time they want to prevent those new folks to make the mistakes that everybody once made: we all started somewhere, and the guys here are mostly autodidact, so most of us have learnt by mistake, trial and error, the hard way. You can’t blame us for trying to defend you from your mistakes - that we made too - to help you get further, quicker, with less hair pulling and fewer grunts.
Now I think the problem is that people don’t tend to learn from other’s mistakes, only from their own. So when you put a lot of effort in a project of yours (and judging by the code, you put that effort into it), you must feel very proud of your work, showing everybody what you cooked up, and even releasing the sourcecode. Now this is the time at which every experienced programmer takes a peek, scratcches it’s head, and probably remembers how it felt like to actually write such code. It’s hard, debugging is a nightmare, it’s not maintainable at all (which might be the least concern for you - as it works!). So it’s only natural for ‘us’ to try to push you in the right direction, while at the same time you feel there is nothing wrong with your code. Please don’t take it too personal. In a few months, you’ll look back at your code and wonder what incredible progress you’ve made since then. You’ll gain more and more experience with programming, and you might change your ways, not because we told you, but because they start to make sense, when your projects get bigger, and need structure for you to work on them, let alone get them debugged, tested and polished.
Seriously, I’ve been programming for almost 10 years now, and I can hardly look at code I’ve written 3 years ago, I get all itchy. Now when somebody else would have read it at the time, and would have told me all that was wrong with it, I might have felt offended, because… it works, I get my own design, I think it makes sense, and who are ‘they’ to judge my code. Well… ‘they’ might have more experience, and only for that reason, I should take such advise seriously, even if I think there’s nothing wrong with my code.
In conclusion, we’re trying to prevent you from making our mistakes, but may be forgetting that those mistakes have contributed to our experience. You need to make mistakes, just not too much, so it helps to be openminded towards seemingly harsh criticism, so your can grow faster than you’d have otherwise managed on your own.
one thing you can do is using checkstyle
I really hate checkstyle because it really takes it up in the fucking ass, but at my former university, if checkstyle reported only one major error on your code, you would get 0 points for your assignment.
http://checkstyle.sourceforge.net/
But adapting your code to every single error checkstyle will output… well I wouldn’t recommend that either
just, I don’t know, read a book or watch youtube link I posted
since you are programming quite procedural you need to learn basic java and OOP stuff, I guess
I really hate to do this because this document is sooooo freaking old but a nice start if you fancy a read 
http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html
The above document could use a revision or two I think but anywho.
// Json
“The paint method takes all the enemies and the player ship and paints them, as long as they are in active state (e.g. not killed). The paint method handles all the gamestates, so the code for the title screen, the boss fight and the pause as well as the gameover screen is also contained in here. The positions of the ships are not updated here, but from the update() call in the main loop.”
Another good candidate would be the collision method. This could at least contain the method of collision detection (AABB, OOBB, Sphere intersection). As a rule of thumb, just thow in some comments as soon as you don’t do something obvious. You will be thankful, once you look at code older than a couple of month, trying to understand, what you were thinking.
Splitting your code into smallert parts is also a way to overcome this. If you have properly named classes (and base classes) and small methods doing one thing and are named like that, you can easily omit most comments, since your code would read like object oriented english text (to all our non-US/non-UK fellows: don’t use your native language in class names and method calls!!!).
Some hints:
Start classnames with a capital letter. Don’t ask why, just do it.
(If you ask why, it’s a distiction of classes and variables for the human readers of your source.
it also helps to identify the constructor of a class)
You could also use accessors (getter/setter) for your fields and don’t use public fields
(this one is debatable; I personally use public fields when I am really sure
that the field will always have read/write semantics and I never would need a
“realtime” change notification. This is in my experience only true for final struct like
datasets/argument containers or temporal instances of private inner classes)
Use separate files for classes
(You might prefer it in one file now, but trust us, you won’t like it later)
Find yourself a decent IDE and learn it’s keyboard shourtcuts (especialy for goto type/class)
(This way, there is also no disadvantage anymore for having classes in separate files)
Use javadoc comments - at least for classes
(Try to describe the purpose of the class in “human readable” form, like explaining it to your mother ;))
Having said that, I don’t find your code too bad, just more like a sketch or prototype instead of a game.
On performance:
PROFILE, PROFILE, PROFILE!!!
Even if you need a week or two to make sense of a profiler, it is the most valuable tool you will have,
not only for performance improvement, but also for memory leak debugging (Yes, this will occur!)
Try to create images/sprites/whatever possible beforehand and only paint them
If you have to create things on the fly, try to cache them and successive only paint them
(only for objects that are expensive to create, don’t cache Points and such!)
For your blur, you combine 5 images into one, couldn’t you just use 2?
Eventually use spatial divisioning for collisions (but probably not be necessary for your amount of bullets/enemies,
but good to know anyway)
One last note:
Don’t whine and call criticism bullshit only because we do not pamper you! 
This is just childish. Have a job? You’ll be surprised what kind of feedback you might get there…
This thread is making me funny.
You said you wanted an example… I’ve only open sourced one thing I’ve ever made, but you can have a look at it if you want.
I’m sure there’s plenty in there that people can criticize me about, but I do at least follow all the Java coding conventions and I’ve Java doc style comments for every single method (even if they’re “obvious”) as well as line-by-line comments.
I’ve really gotten in the habit of putting a single line comment above almost any line in my code. Stuff that is obviously together, like:
x += dx;
y += dy;
Obviously only gets one comment, but I’d put a comment in there even though the functionality is pretty obvious.
i.e.
//Moves the object by the change amount.
x += dx;
y += dy;
The whole reason for all this is so that theoretically anybody anywhere could understand your code just by reading a bunch of comments, never needing to actually read a line of code. Every bit of functionality should have a comment about it, to the point that you could make a big pseudocode summary of your code with just comments.
This also makes it really easy to port your code over to other languages, which can be very important in a professional environment.
And comments aside, putting all your classes in one java file isn’t a good idea, like everybody has told you already. Sometimes it makes sense (like Point2D.Float Point2D.Double) or in my code MazeGenerator.Coordinate, but you do that when that class is inseparably linked to the main class in the Java file. As in, the Coordinate will never be used unless you’re dealing with a MazeGenerator. Private classes are useful for stuff like ActionListener implementations, but once again you typically want to split everything up as much as possible. There is no right way to do this, and you’ll see some people decided to couple two classes together while others won’t, but you should always at least have a reason if you’re going to embed classes.
(Also, before you harp on my code, I should note that the comments are in the areas that are meant to be learned from - the maze generation. The Swing stuff in the GUI has practically none at all because that’s just so people can test the maze generator)
Please don’t give up. Opening your source can be very useful, my game would have never existed if Vincent Stahl had not opened the source of Art Attack. You cannot predict how it will be used. Thank you for your contribution and try to learn from the (sometimes harsh) critics.
just a short question at you demonpants, or at all
I really hate something about java codeconvention, which is different then C++
I mean the open bracket after the method declaration and not beneath it
I noticed that you also not do that, since I saw your code
public static void main(String[] args)
{
new Main();
}
I really think that it’s much easier to read that way
… so you CAN do it without getting beaten down ? =P
I prefer it that way as well and I agree its A LOT more readable however work is using the damn Sun code convention so I need to go the other way. But I just have the Eclipse auto formatting enabled as a save action on all my altered lines of code
// Json
++ I found that much more logical too as the brackets have nothing to do with if/else/while etc… so this is pretty unlogical to not put those on a new line as it delimit unbreakable/local code block and can be used without specific instructions before.
{
double x=3;
}
String x="2";
for(int n=0;n<10;n++)
System.out.println(x);
However I dont do what you did there, not doing brackets because its just one line, although you might do it =P
brackets exists to make a bunch of code to appear as only one instruction/line, you put brackets because you have more than one line or you are doing something like “I make my single line appear as a single line” wich is useless.
EDIT :
IF act like the following
if condition
do this single instruction (and so requiere brackets if you have more then one things to do at once)