Geeks With Blogs
The Stumblings of an IT Manager ...2 days before we go live and you want WHAT....?

I was recently working in a section of an app that really made me think, "is this good code?".  Specifically, in the business logic section there was a single class for a major "functional object", the class was just over 4700 lines of code (with very very little documentation, I would guess less than 1% of the total).  Is that bad? Should that be split up over some sort of Object_FunctionalArea.cs type of breakout, or does that muddy the water so to speak?  Generally, I feel that keeping classes in a more "manageable" size of less than 1000 lines, and when I start approaching that number, I normally feel that I need to re-visit the architechture of the item.

Along the same lines, running across a SPROC that was just under 500 lines made me cringe.  You can assume that this is a single shot line of functionality with almost no chance of re-use.  I understand that this happens, but normally something in the DB that is this large, smacks of business logic (that should IMHO be placed in the BLL) that needs to be stripped down, and broken out into smaller functions. I understand that at times, there is no way around this, but that should be the exception, not the rule.  I hope that I am not the only person thinking along these lines, but I digress.  What are your thoughts?

Posted on Friday, January 22, 2010 3:39 PM | Back to top


Comments on this post: Good thing or bad thing - How much code is too much for a class/sproc

# re: Good thing or bad thing - How much code is too much for a class/sproc
Requesting Gravatar...
I would have to agree that smaller is definately better. I think a 4700 line class is a bit excessive unless there was a really really good reason to not split it out some how. If it were me, I would find a way to refactor it out to several smaller classes if at all possible. There are always edge cases, but they are ususally few and far between.

I personally don't mind classes without much documentation as long as they are logically designed and self-describing. I actually prefer it when possible, tons of comments can make it hard to read the code that is there.
Left by Dane Morgridge on Jan 22, 2010 4:14 PM

# Keep Classes Small
Requesting Gravatar...
4700 lines of code in a single class? With no documentation? Good lord!

I'm not an expert by any means, but I have to imagine that a class that large is next-to-impossible to maintain. I understand that there's a good deal of business logic in there, but I have to imagine that many parts of that class could be broken off into sub-classes or utility methods.

I start to cringe when I write classes over 300 lines - it's just much harder to wrap my head around the methods and properties of the class in question.

I'll put it this way: if you could maintain the code more easily (and make stable changes more quickly) with larger classes then be my guest. I can tell you that I can't do it.
Left by Arthur Kay on Jan 22, 2010 4:55 PM

# re: Good thing or bad thing - How much code is too much for a class/sproc
Requesting Gravatar...
i can't believe i have to say this, but a 4700 line class is utterly absurd.

http://en.wikipedia.org/wiki/Single_responsibility_principle
Left by Len Smith on Jan 25, 2010 2:58 PM

Your comment:
 (will show your gravatar)


Copyright © AndyScott | Powered by: GeeksWithBlogs.net