How to convince people that a single class with 11975 lines of code is bad? (isn't it?) [closed]

Question

I have a dejavu feeling when reading [What to do about a 11000 lines C++ source file?] post, but I don't think I can start taking action on my own since I do not have the authority to take action. So I think the first step is to convince people in the organization that big lump of code is bad.

I have a similar situation where there is a single class with 11975 lines of code and every time there are new features, there is a high probability that this class will get bigger and bigger.

Answer 1

You have my sympathies. Any class that is that huge is inevitably breaking the Single Responsibility Principle, making it difficult to maintain.

My best advice is to lead by example:

• Keep your new code small.
• Refactor mercilessly when changing code to reduce the size of classes and functions.

Your code will shine like a beacon compared to a the legacy code and your team will understand which code is easier to maintain.

Answer 2

11975 (or is it 12000 already :)) lines of class implementation. Is it bad? Cerainly looks so. But...

It depends. Typically classes which implement the Mediator pattern or the Facade pattern tend to be very large. They have very complex routing / communication protocol. "God" like classes also tend to be very huge and monolithic. In short, A class may actually be large but that may not be a problem.

So instead of focussing on the LOC as a parameter, focus on the functionality / design of the class. Is the class violating Single Responsibility Principle? LOC alone cannot be the only deciding factor to conclude if a class is really huge. Look at other metrics e.g. Cyclomatic Complexity.

However if you conclude that this is really bad in your project's context, you must have a strong reason to convince the relevant stakeholders. For example,

a. Does this class have many bugs?

b. Do this class bug fixes always introduce regression defects? (High coupling, Low cohesion?)

c. How long do defects take to be fixed in this class? How does this compare with other modules?

d. Generate a few UML diagrams for this module to illustrate the important issues (e.g. coupling).

e. Read as much on metrics / consult your Quality / Metrics / QA team and generate sufficient data points. An example of OOAD metrics is here but I am sure there are plenty.

EDIT 2 (some minor changes)

f. Get initial support from some key stakeholders in your sphere of control. Next, get, someone who can present these facts well!. I have seen many things fail at this stage!.

Good luck!

Answer 3

Tell them to summarize what the class does\represents in a minute.