I'm maintaining a Java class that's 40K lines long.. problem?

Question

This may be a subjective question leading to deletion but I would really like some feedback.

Recently, I moved to another very large enterprise project where I work as a

Answer 1

50K lines of code? I thought KLOC was a metric of project size, not file size. That's like our whole codebase (including tests).

I'm working with JavaScript, so it's not directly comparable, but we only have few files that are over 500 lines long - and these are the highly problematic ones.

Answer 2

As a young programmer I still remember my teacher telling us to break up big functions and work on a good OO design before writing code.

So unless there is a REALLY good reason in your design to impose 40k lines (which I strongly doubt) then you already have your answer : your class is too big.

I will quote my wife (who is chemist and doesn't program) : "40k lines of code, there is something really wrong!"

I've had friends take up projects in their companies that were really old, tossed from one programmer to the over and what we all agreed on is that a class that size simply means:

-patch and fix : people had to do minor changes here and there and didn't want to/ didn't have the time to do it corretly.

at runtime there might not be any problems with that code, everything works, but usually problems occure when you want to do any form of modifications:

• it takes ages to find anything

• when there is a bug you can't pin point it easily

...

In conclusion I would sit down rethink the oo design of your project and restructure (at least into 1k ~ 5k lines classes to start with), I know its annoying to do bu usually on the long run its better

Answer 3

Oh, I think this a terrible sign, and I don't have to look at the code to say so. Sounds like a massive refactoring effort is needed.

Let me guess - you have no unit tests for the system as written, either. You have my sympathy.

Answer 4

A small thing to pay attention to is the difference between lines, lines of code, and statements. If you analyze your project with e.g. Sonar you can easily see the difference between those.

Nevertheless, whatever the exact measure, 40k lines of business code is hideous.

In the business module of an enterprise application I develop, the highest number is 444 lines of code. This is for a rather large Service. Most Service classes are between 200 and 100 lines of code. Entities (model objects) are in our situation mostly between 40 and 100 loc.

In another part of this same application we have one class that is 1224 lines of code (2477 lines total, 706 statements). This class is almost universally hated within the team because of its size. It's perceived as bloated, complicated and doing way too much.

Now if an entire team thinks this about a class that's only 2477 lines total, this may give you some perspective about what kind of abomination a 40k lines class is.

Answer 5

I think your aghastness is qualified :) I can't imagine that the program is properly OOPified. Classes are a bit tougher to classify, but methods are easy: 1 behavior per method (that's not a rule, but it should be). Behaviors can't possibly be even close 1k lines of code. At least, as far as my imagination will take me.

Classes, on the other hand, can represent many things but they should represent something. If it is difficult to tell what the class represents, then you have a problem.

Now, I half imagine that you are well aware of these concepts and I'm preaching to the choir. So, I'll just pretend like I didn't go off on a tangent there and answer your question directly:

Yes. Very unfortunately, it is remarkably common for large enterprise projects to have code that lazy. I have worked on projects almost as large (yours shoots anything I've seen out of the water) and my first tendency is to start breaking things up into logical components, particularly in places where I intend on making changes. I can't handle that kind spaghetti, it's too irritating.

Answer 6

I know some section of code needs breaking up when I have problems trying figure out what it does and how. Or if its larger than a screen-shot.

Typically I refactor it if it makes me feel bad. I don't like feeling bad :-(

I suspect the code got out of control because the management just wanted bugfixes/features done and nothing else, and bit by bit it slowly got worse.

Refactoring the code to make the programmers job easier was probably not very high on their list of priorities. The management always want their bugfixes/features yesterday :-(

Also a working program is obviously better than one thats broke, and breaking up code that large without unit-tests would end in disaster. So all the tests would have to be made before touching the code. Yet another reason management wouldn't allow it.