aspose file tools*
The moose likes Java in General and the fly likes What size for a good java program? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Soft Skills this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "What size for a good java program?" Watch "What size for a good java program?" New topic
Author

What size for a good java program?

ta ton
Greenhorn

Joined: Jul 15, 2001
Posts: 4
Hi Everyone,
I'm doing a research on Java language and review a few programs which written by someone else. The size of each program is about 8000 lines or 150 pages of A4. The program is a very crowded screen with hundres of fields required to validate. Initially, I felt overhelm by its size but the programmer insists codes need to be in one program but I read in java code convention stated a java program should not be more than 2000 lines. Could you please give me advices what size for a good program. If it is big could we break it into smaller classes? In this case, a screen design using swing, should all codes be together in one place?
Thanks in advance.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
In my experience big classes (what I understand you are referring to with the term 'program') are a bad thing. My first classes were big, but now I try to write classes consisting of not more than a dozen methods, each very small (say, ten lines of code) and doing exactly one thing. Every time I feel tempted to split a method into two or more blocks of code (by inserting an empty line and perhaps a comment), I just go one step further by splitting it up into different methods.
One advice: Read the book "Refactoring" by Martin Fowler. It is great and will most probably change the way you look at code dramatically. Well, I would say reading this book was the first time I really groked what oo programming is about.
Two discussions regarding this subject:
http://c2.com/cgi/wiki?ClassesWithoutOo
http://c2.com/cgi/wiki?LotsOfLittleMethods
[This message has been edited by Ilja Preuss (edited July 16, 2001).]


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
jeevan pingali
Greenhorn

Joined: Jul 16, 2001
Posts: 1
There are a few things need to remember -
i) Follow strict OOPS
ii) Try to reduce dependencies (as per Software Engineering do
black box testing and white box testing.)
These are the core requirements.
Just chopping the classes into small pieces will spoil the
intension an increase dependencies.
Thomas Paul
mister krabs
Ranch Hand

Joined: May 05, 2000
Posts: 13974
8000 lines for one class?! That's poor coding technique. I would say that it was written by a programmer who needs a course in the fundamentals of OO.


Associate Instructor - Hofstra University
Amazon Top 750 reviewer - Blog - Unresolved References - Book Review Blog
Scott Palmer
Ranch Hand

Joined: Jul 11, 2001
Posts: 31
I personally feel that measuring code complexity based on lines of code is usually unfair. It is a good clue that there is <em>probably</em> some design problem. But I don't think it indicates a problem as a rule.
E.g. What if the structure of the program really was simple - like a huge case statement that had one method call per case. Assume that polymorphism and a single call to a base class method isn't posible in this case. In other words the structure is simple and straight forward, easy to understand - the size is simply 'big'. That isn't always a problem, sometimes things might just be big because that's how it is.
Is it not possible that attempting to divide something up into smaller bits can end up fragmenting what is really a single concept or thought that should have been treated as a unit on it's own. Could it not be elegant despite its size?
I've seen people take forever to get things coded and working because they struggle trying to fit their code to all these "rules of thumb" as if they were laws. Usually they could have a perfectly understandable and working solution that is simple enough to understand and not likely to cause maintenance issues if they would only realize that all the books on their shelf are full of guidelines, not "commandments".
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
I personally feel that measuring code complexity based on lines of code is usually unfair. It is a good clue that there is <em>probably</em> some design problem. But I don't think it indicates a problem as a rule.

Of course a rule like "all classes have to be smaller than xxx loc" is just silly. Nevertheless I am convinced that a class of 8000 lines just is a problem.
E.g. What if the structure of the program really was simple - like a huge case statement that had one method call per case. Assume that polymorphism and a single call to a base class method isn't posible in this case. In other words the structure is simple and straight forward, easy to understand - the size is simply 'big'. That isn't always a problem, sometimes things might just be big because that's how it is.

Perhaps I just can't imagine a problem making such a huge switch statement necessary. If you could provide a real world example...?
Is it not possible that attempting to divide something up into smaller bits can end up fragmenting what is really a single concept or thought that should have been treated as a unit on it's own. Could it not be elegant despite its size?

Possibly your head is much bigger than mine, but I just don't get such a huge concept into my mind as one unit. Usually it's much better for me to reduce the complexity of the problem by abstracting it and handling all the tiny little details at other places.
I've seen people take forever to get things coded and working because they struggle trying to fit their code to all these "rules of thumb" as if they were laws. Usually they could have a perfectly understandable and working solution that is simple enough to understand and not likely to cause maintenance issues if they would only realize that all the books on their shelf are full of guidelines, not "commandments".

Of course it's always a problem if you use these rules as an excuse for not thinking about what you are doing. However, I have seen far more people producing really bad code because they thought of these rules as just theoretical subtlenesses without any relevance for "real programmers getting real problems solved".
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
I suppose it's theoretically possible that certain types of problems might be best served by a class with 8000 lines, but it seems pretty unlikely to me. I'd have a buzz saw at the ready while I was looking at such a class. The last time an interviewer asked my how many lines of code I had written in a project, I looked blankly at him and replied that my most productive days were when I removed lines, not when I wrote them. (I don't think he understood, but oh well.)
[This message has been edited by Jim Yingst (edited July 17, 2001).]


"I'm not back." - Bill Harding, Twister
Scott Palmer
Ranch Hand

Joined: Jul 11, 2001
Posts: 31
I guess part of my point was that in my hypothetical argument if this single file was turned into 1000 smaller files I think that things could be made more complicated and convoluted.
It all depends on the particular problem at hand. Seeing a size of 8000 lines is enough for us to say "whoa! That doesn't seem right." But it isn't enough to say "It's wrong - that is not a good java program." It doesn't make sense to say that until you see the code for yourself and understand the problem it is trying to solve.
That's my theory anyway... I can't think of a particular example for a 8000 line file - but I've had similar things come up on real projects (where rules of thumb were taken to the extreme resulting in uneccesary delays).

ta ton
Greenhorn

Joined: Jul 15, 2001
Posts: 4
Thank you all for your comments, advices. The project I've mentioned having some very big classes. The biggest is 9,920 lines of code. It worked and sastified user requirements but in developer's point of view I feel it may be difficult for others to maintain later when debugging thru thousands lines of code. Since it worked and the project's approaching delivery date it's hard to convince them to rework on these classes. Could you please advise how to solve this "problem". Thanks.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: What size for a good java program?