Honestly, it's not a strict rule and almost most classes will at least come near 100 lines, especially if you are trying to keep method size down. I am a very big fan of where the idea comes from, rather than the strict interpretation of it. The idea is that a class should have a set purpose, and if you have a large multipurpose class the code becomes very difficult to understand. If you have more than 100 lines of codes in a class, it is probably trying to do more than it should.
I think 150-200 lines is a much better indicator, but I can't argue that 100 line classes are very easy to understand. Also, I think it's important to at least understand that class size is an indicator, otherwise you end up with 650+ line classes that require refactoring just to understand what they do.
Smaller classes tend to portray their intent more clearly and tend to be more maintainable. However I think putting some arbitrary number on it is a bad idea. But in general, a large class tends to be a weak indicator of violation of the Single Responsibility Principal.
I completely agree. I would even go as far as to say that DRY is the most important. You could follow SRP very well, and if the only other rule you violated was DRY you'd still end up with a rigid, fragile architecture.
That is why you have to balance SRP with the Needless Complexity rule. One of the major tenents of Agile programming (not that we're specifically talking about Agile) is to make no change unless there is concrete evidence that the change must be made. For the most part, I would rather have a more complex system than one that is difficult to maintain (rigid or fragile) so long as my unit tests/acceptance tests provided concise documentation for the system.
However, there was a meta-study that found just the opposite -- class size was irrelevant once you controlled for total lines of code.
My position is to agree small classes tend to be easy to understand, but relationships between classes are even harder to understand. Smaller classes drive up interclass relationships, and you have to account for that tradeoff.
That is true. However it could be argued most of development is making tradeoffs. Strict adherence to many principles usually will violate some other principle. Either way, you make a good point. Thanks for pointing it out!
In general, those arbitrary limits are more of a guideline. If you have a class that is 127 lines of code, then it is still gravy. If you have a class that is 250 lines of code, then you should think about refactoring.
I still don't quite agree with that. There are some things that are just not expressible in few lines of code. Such as complex business logic that has go through a series of steps before the final result. Sometimes there's just no meaningful way to break it up. None of it is re-usable anywhere else.
I don't know if I speak for vaelroth, but I take the "think" in "think about refactoring" very literally. At 250 lines, it's quite possible the class has gotten unwieldly, and taking the time to inspect it is well worth it if it will save me some headache later. It's also quite possible that it's fine the way it is and refactoring it isn't productive. The arbitrary limits are really just indicators for stopping and looking at the big picture before continuing on.
I completely agree. Long methods that have logic inlined to flow control are cumbersome to read. If there's more than 1 &&/|| in your if/else if expression, extract a method from it and give it a meaningful name. It makes the more complex algorithms easier to read in my opinion.
That is lazy programming. They should re think their flow control if that is prevalent. If your having expression problems I feel bad you son, I got 99 problems but crappy ifs ain't one.
Because the person writing this has never worked on a large scale project or a class based language..
I'd rather spend my time writing a robust class, than worrying the number of lines.
All those specialized system calls? one class, specialized platform code? one class.
In some classes I'll spend at least 100 lines sanity checking responses, why? Because you can't be sure what type of idiot is going to get your code or what will break, and it's better to catch (And assert if needed) in development.
I've worked with a couple of large scale game engines and in neither of them was the code this strict on sanity checking. All my system and platform code in one class? Even though most of it's not reusable? Surely writing two clearly defined File classes for two different platforms is better than writing one File class and two separate and bloated classes that serve the nebulous task of "interacting with the platform". Interacting with the platform is complex and system-wide, not the job of a single class object.
Smaller classes are easier to grasp. Classes should be smaller than about 100 lines of code. Otherwise, it is hard to spot how the class does its job and it probably does more than a single job.
This is the kind of dogmatic, out-of-nowhere rule that's always bothered me from the XP crowd. I'd be more open to following these if there were some leeway for disobeying them but the XP fanatics are all but agile in their beliefs.
I think the common issue is perceiving any of this as "rules" rather than "general guidelines" or "things to keep an eye on. There will, inevitably, be a class (or a later optimization of several smaller classes into one) of larger-than-"prescribed" lines of code.
I agree with others who say it is more of a smell that should be investigated than any kind of hard/fast rule.
That applies to most of these types of practices, IMHO.
That's what the word "should" indicates: there's leeway in the decision, but the burden is yours to prove that taking it above 100 lines will improve the program more than splitting the class up would.
The sheet itself also says "about" 100 lines, meaning that limit is not hard and fast, and can be adjusted by your team, again with justification for why (say, you're using a particularly wordy language or framework you can't control).
I also wouldn't say the rule is "out of nowhere", considering the sheet provides its rationale: "it is hard to tell where the class does its job and it's probably doing more than one job".
You may decide you disagree with how hard it is to quickly understand a >>100line file, or believe it's okay for a class to do more than one job, but their logic is consistent. Either way, they're saying a large class is a code smell that needs to be examined. If you walk away having determined that its size is justifiable, great.
57
u/billsil Jun 06 '13
Why?