Geeks With Blogs
Dave Chestnutt: SparklingCode and CodeGaffes Writing better code; for fun and profit
One of the benefits of using modern editors is that it's really easy to navigate your code base. If you're looking at a method call, for example, you can use a keystroke combination to jump to the method definition.
 
But there's a drawback to this.
 
If you're not careful, as you add new code you can end up with monster methods, or monster-sized classes. Let me ask you this - what do you think the maximum size of a class should be? 100 lines? 500 lines? 10,000 lines? While we won't agree on an exact number, we can all agree that a class with 10,000 lines in it is much more likely to have bugs in it than one with 100 lines.
 
But no one sets out to write such a huge class. How does it get this way? Simple - over time, various people make little modifications to a class. How many times have you looked at a modification and thought to yourself, "Perfect, I'll just add these lines of code here, and it'll support the new feature." After enough people do that, your 500 line class grows and grows. And grows!
 
Here's a fairly innocuous bit of code. If I had just added this, without line numbers being displayed, I might not realize how big the class already is. But, as the screen shot on the right shows, I might be more inclined to realize that I shouldn't grow this class any further since it already has nearly 20,000 lines of code in it!
 
No Line Numbers Line Numbers show a problem!
     
 
Thus, my advice: turn on line number display in your editor. In Visual Studio, turn on Line Numbers by going to Tools | Options | Text Editor and check Line Numbers
 
 
Now, when you're fixing bugs or adding features, you'll see line numbers. And when you get near the bottom of a file, you'll have another reminder that the class is growing out of control. Then you can plan some refactoring to break up the monster method or class. And improve your code base.
 
Turn on line numbers in your editor. They're an early warning system.
 
Technorati tags: ,
Posted on Monday, January 30, 2006 6:46 PM CodeGaffes , Visual Studio Tips | Back to top


Comments on this post: SparklingCode: Count the cost with Line Numbers

# re: SparklingCode: Count the cost with Line Numbers
Requesting Gravatar...
at a previous (not named to protect the guilty) position, I opened one form to discover to my horror ....


8900 lines of code.

nuff said.

Does anyone still have a VT terminal? they have a great way of forcing you to write better code:)

Greg
Left by Greg Young on Jan 30, 2006 8:55 PM

# re: SparklingCode: Count the cost with Line Numbers
Requesting Gravatar...
20,000 lines of code in one class !?!

You've got to be kidding. At some point you have to think about the benefits of refactoring.
Left by Brian on Jan 31, 2006 5:35 AM

# re: SparklingCode: Count the cost with Line Numbers
Requesting Gravatar...
Yes, 20,000 lines is obviously a problem! Unfortunately, I've seen monster classes like this.

When a group is under pressure for a year or two, people will often simply think about doing the minimum to "just fix the code". Why? Because they get measured by how many bug fixes they do - not by how many bugs they prevent. And because of that pressure, they may not even realize how big the class is growing.

I've rarely been on a project where I could schedule time to do refactoring and general cleanup, even though all code would benefit from time spent fixing it up. However, I can always do some refactoring and cleanup "on the fly" as I'm doing other work. So I'm all for using any tricks that help me realize a class or method is in trouble (and line number display is merely one such trick).
Left by Dave Chestnutt on Jan 31, 2006 5:51 AM

# re: SparklingCode: Count the cost with Line Numbers
Requesting Gravatar...
Good advice. I've been using line numbers for a few years now, and it's very helpful. I guess I use it more for bragging rights. ("Hey boss, I've written 1,500 lines of code today. Aren't you impressed?" or "Hey Boss, this project has 250,000 lines of code. Aren't you impressed. I think I should get a raise.")

I do have one question. Is this an issue with performance, or pure sanity when finding bugs, etc? It doesn't seem to me that the CLR would care whether a class is 100 lines, or 100,000 (but I may be wrong). So is this an issue of performance, or convenience?
Left by Kyle on Jan 31, 2006 7:00 AM

# re: SparklingCode: Count the cost with Line Numbers
Requesting Gravatar...
This is a code quality issue, not a performance issue.

First of all, I'm assuming that all the code is used. If it's not being used, just delete it.

But whether it is or not, the CLR is pretty good at JIT compiling methods as they are used for the first time. So, whether the code is sprinkled out over several classes, or glommed together in one giant class, it probably won't affect performance.

However, I would venture to guess that in many cases, if the code has gotten that large, it's quite likely there are redundant code paths in it already. So, cleaning it up may reveal junk that can be deleted or merged.

But to answer your original question: Large classes/methods are bad from a code quality standpoint (as well as sanity). The bigger the mess gets, the harder it is to test all those code paths. By going the way of lots of small classes, you can unit test each one to effectively validate it.

And don't forget another key premise of good code design: each class must have a clearly defined responsibility. Don't just break it up willy nilly. Otherwise, to paraphrase the movie "Independence Day", you risk turning one yucky object into many yucky objects. Just breaking a class up randomly into many files won't help. Break it up with an eye towards extracting cohesive bits of functionality into separate classes that do one thing and do it well.
Left by Dave Chestnutt on Jan 31, 2006 12:39 PM

Your comment:
 (will show your gravatar)


Copyright © Dave Chestnutt | Powered by: GeeksWithBlogs.net