lemme gess ur 8 year old yer fucking bastard
[quote]ive tried already
[/quote]
If this is referring to shooting yourself in the face, it’s a goddamned shame you didn’t succeed.
Somebody with moderating/admining privledges, PLEASE IP ban this guy and delete all of his posts, and all of mine that respond to him.
Please.
[quote]lemme gess ur 8 year old yer fucking bastard
[/quote]
CLOSE ;D
ROFL.
/me is already LOL at “For the love of humanity, take one for the team…”
Please, someone with administrator privileges: change his avatar to one of eric CARTMAN.
That will do it for me 
Back on topic.
I did say not to take the code literally, or maybe I should have said “example”.
Regardless, getters and setters are sometimes evil.
High order functions such as “destroyWorld” should be legal, the way that I have shown.
When I write a program I only want to expose the most important features, doing so in a large program can lead to complexities such as the one I described above.
[quote]In java, no class should ever be more than 1000 lines of code, including all comments and all javadocs.
Entirely IMNSHO, of course, but from long experience, and lots of code reviews over the years, I’ve found the sweet spot is that any class with more than 750 lines of code is almost certainly “wrong” or “broken”: if you ever hit 1000 lines, you know something is DEFINITELY wrong.
Shrug. Just a tip.
[/quote]
Just few words. Image processing library.
It looks more like Java.math than normal class. If I’d add spiders inside (they are better in different class) it might be over 3800 lines.
BTW I thinks java docs in source code are making the source code less readable, and unnecessary larger. It would be much nicer if Javadocs would be GUI application that would write some external files and then merged them into documentation.
But if your javadocs were in external files and for whatever reason you just had the source code files, no matter how well written the code was it would be a good deal harder to interact with it.
If anyone gives you a size constraint, ignore them. In fact if anyone ever gives you any constraints, ignore them. Do what you have to do to make it work. Worry about making it fast later, and finally, when it’s working and fast, worry about making it pretty enough to show off.
Cas
Heh, I have one class with 98617 lines and I’m 100% sure there’s not one bug in it. ;D
Is that the class that begins “/" and ends with "/” ?
LOL ;D
No, it’s a generated one. It emulates all possible MOVE commands in an 68k cpu, and there’s LOTS of them.
[quote]But if your javadocs were in external files and for whatever reason you just had the source code files, no matter how well written the code was it would be a good deal harder to interact with it.
[/quote]
I believe there should be two types of comments, one for programmers that would like to do something weird these shouldn’t be in JavaDocs, and the other type for general use.
to erikd. Hand generated are better. ~_^
I believe there is such a convention. The comments describing the inner workings of the functions is positioned right after the function declaration:
/**
* Gets the x component.
* @return the x component.
*/
public float getX() {
/*
Describes what the weird code does.
*/
return (somethingWeird);
}
Quite. An extra layer for documentation sounds like more complication for no perceptible gain. Kind of a backward’s occam’s razor, if that makes sense.
I’ve asked a teacher during my labs if this is acceptable:
a.getA().getB().getC().
She said ‘yes’.
Of course I worded the question as:
“Does it break any OOP or UML 2 rules if I get a reference object in another class with a getter and get another object from that class?”
It would be classed as breaking the law of demeter ( http://c2.com/cgi/wiki?LawOfDemeter ) but frankly I always thought that rule was junk anyway, you can always work around it but you end up with some hideous code.
Personally I like the XP style method of code the simplest thing possible and refactoring it when I need to, instead of the whole “big design upfront” method where things tend to get overcomplicated.
jf1.getContentPane().add(something);
is a simpliest exameple of such usage.
Of course if it would go to extremes programmers could use
Something s = …getSomething(Object);
s.doWork();
s.check();
or
private Something getSomething(Object something1, Object somethingElse)
[quote]I’ve asked a teacher during my labs if this is acceptable:
[/quote]
The answer is really “only if your IDE has a one-click function to unroll it for you” because in real development you very often have to unroll those things later on when you’re maintaining / updating / adding new features. 
Most IDE’s do this these days (yes?) so it’s not a problem.
So … what?
I have no idea what spiders are, and I’ve no idea what you’re saying here. Are you trying to defend a 4k line class?