Win a copy of Mesos in Action this week in the Cloud/Virtualizaton forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

What size for a good java program?

 
ta ton
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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).]
 
jeevan pingali
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 13974
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Scott Palmer
Ranch Hand
Posts: 31
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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).]
 
Scott Palmer
Ranch Hand
Posts: 31
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic