[ACCEPTED]-In C# how many lines before a class should be consider to be refactored?-class

Accepted answer
Score: 44

When the class violates the SRP, it's time 8 to refactor.

The single responsibility principle 7 is a computer programming principle that 6 states that every module or class should 5 have responsibility over a single part 4 of the functionality provided by the software, and 3 that responsibility should be entirely encapsulated 2 by the class. All its services should 1 be narrowly aligned with that responsibility

Score: 21

If your classes have broken one of following 18 "rules", you should consider to 17 refactor.

You are looking for SOLID, more detailed 16 screencasts can be found here.

  • SRP: single responsibility 15 principle, there should never be more than 14 one reason for a class to change.

  • OCP: open 13 closed principle, software entities (classes, modules, functions, etc.) should 12 be open for extension but closed for modification.

  • LSP: liskov 11 substitution principle, functions that use 10 references to base classes must be able 9 to use objects of derived classes without 8 knowing it.

  • ISP: interface segregation principle, clients 7 should not be forced to depend upon interfaces 6 that they do not use.

  • DIP: dependency inversion 5 principle:

    • high level modules should not 4 depend upon low level modules. Both Should 3 depend upon abstractions.

    • abstractions should 2 not depend upon details. Details should 1 depend upon abstractions.

Score: 8

Don't let LOC be your primary metric. 50 14 lines seems really small to me. With 50 13 line files, you will end up having an unfriendly 12 number of class files in the solution. Your 11 productivity will be dampened by all the 10 navigation you will be doing between files 9 and your IDE will always be littered with 8 too many tabs. I personally try to organize 7 classes into logical groups by namespace 6 first. On a class by class basis, I try 5 to make the code smaller and easier to read. Sometimes, class 4 files do get large. I start to get a sick 3 feeling when the class file is 2000+ lines. Anything 2 less than that, I deal with on a case by 1 case basis.

Score: 6

I wouldn't say that there's any "rule of 36 thumb" for refactoring large classes. Sometimes 35 a class really encapsulates a lot of business 34 logic and should be as large as it is. However, you 33 might consider asking yourself a few questions:

  1. (Assuming 32 you're writing object oriented code) Is 31 my code truly object-oriented? That is, does 30 it follow the Single Responsibility Principle 29 (thanks, Nebakanezer)? Is this class a helper 28 class? If so, how could I refactor its methods 27 into more appropriate object classes?

  2. Do 26 I have a solid architecture? That is, am 25 I making use of abstraction and inheritance 24 rather than re-inventing the wheel in every 23 class? Are overloaded methods calling base 22 methods as appropriate?

  3. Do I really need 21 all this code? Could some of the logic be 20 externalized using xpath, lambda expressions, or 19 some form of database driven expressions?

  4. Is 18 the code extensible? Is it easy to maintain? Was 17 it well-architected from the beginning, or 16 are we always making small patches to try 15 to fix problems?

I hope that this helps a 14 little; it can be difficult to refactor 13 large classes, but I think if you start 12 looking through my questions, you may find 11 pretty quickly that there is room for improvement 10 in your code...I know I typically do.

Especially 9 look at #1--it's really common for people 8 to create a ton of helper classes all over 7 the place, which is very anti-object oriented 6 (in my opinion). That's a different topic, but 5 you may want to see what really -belongs- in 4 the class you've made and what could/should 3 be somewhere else.

As a rule of thumb, if 2 the class is maintainable and flexible, it 1 may not need to be changed. :)

Score: 4

In C#, my rule of thumb for classes is anything 4 over 500 lines is getting too long. I really 3 like methods under 10 lines, and I guess 2 under 20 is acceptable. I think it really 1 depends on the context.

Score: 3

Refactor whenever you have the opportunity 3 to:

  • introduce the appropriate design patterns in lieu of spaghetti code
  • reduce code complexity and increase readability
  • remove redundant code by introducing a single method call
  • extricate UI from business logic

etc, etc.

EDIT: Obviously, the decision 2 to refactor should take into account time, potential 1 pay-off, other responsibilities, etc.

Score: 2

My rule of thumb is for methods, more than 3 classes - If I can't see the whole method 2 on screen it needs to be refactored. Of 1 course, the traditional smells apply.

Score: 2

I tend to look at the cyclomatic complexity 2 of each member instead of number of lines 1 of code for the entire class.

Score: 1

Refactoring is not so much about reducing 4 the number of LOC, though that is a side 3 effect, but improving the quality. Particularly, you 2 want to try to follow the DRY (Don't Repeat 1 Yourself) principle as much as you can, reasonably.

Score: 0

This class could be a candidate for the 14 refactoring exercise of "extract an object 13 that you don't think is there"?

Perhaps, for 12 example, you could extract a method object 11 that would allow you to refactor several 10 of the 50 line methods into members of an 9 extracted class?

Alternatively, encapsulating 8 some of those private methods that contain 7 business logic in a new object that collaborates 6 with this one might provide a new way to 5 reuse either this object, or the extracted 4 one.

One line is enough to consider refactoring. 40 3 each 50 line methods is starting to scream 2 "I'm too complicated, there's another object 1 hiding in here" to my ear.

More Related questions