dcsimg
Comments vs. "Extract Code"
3 posts in topic
Flat View  Flat View
TOPIC ACTIONS:
 

Posted By:   Jon_Thorarinsson
Posted On:   Monday, December 15, 2003 08:21 AM

I'm sure that a lot of you are familiar with the "Extract Code" refactoring method. You can find a thorough description of it in the book "Refactoring - Improving the design of existing code" by Martin Fowler. You take a chunk of code and make a method out of it. This is particularly useful to do with long methods. You're essentially splitting the method in smaller methods to make it more readable and more maintainable. My question is, when is it better to use comments instead of the "Extract Code" pattern? I've found that if you overuse the Extract Code refactoring, the code can become more complex than it was before. Maybe the answer is that a class shouldn't have any private meth   More>>

I'm sure that a lot of you are familiar with the "Extract Code" refactoring method. You can find a thorough description of it in the book "Refactoring - Improving the design of existing code" by Martin Fowler. You take a chunk of code and make a method out of it. This is particularly useful to do with long methods. You're essentially splitting the method in smaller methods to make it more readable and more maintainable.


My question is, when is it better to use comments instead of the "Extract Code" pattern?


I've found that if you overuse the Extract Code refactoring, the code can become more complex than it was before. Maybe the answer is that a class shouldn't have any private methods that are only called from one place. But Martin Fowler doesn't seem to think so. But code that is mostly endless delegations can't be good, either. So where do the boundaries lie?

   <<Less

Re: Comments vs. "Extract Code"

Posted By:   Simon_Ablett  
Posted On:   Monday, December 22, 2003 06:31 AM

The rule of thumb should be that a method should perform one and only one unit of work. If it looks as though a method should perform multiple units of work then it should be split into multiple methods all of which should be called by an outer method whose unit of work would be stringing the other units of work together (i.e. invoking them). As an aside, even 'small' methods should be adequately commented. There's no such thing as self-documenting code.

Re: Comments vs. "Extract Code"

Posted By:   Anonymous  
Posted On:   Wednesday, December 17, 2003 02:00 PM

My experience is that it is almost *always* a good idea to split a big method into several smaller ones. You need to take into account that this does not have to be the final state - often there is a follow up refactoring, such as moving the new, smaller method to a different class because of the envy code smell.

Can you show us a method of which you think that splitting it up would make it more complex? It would be interesting to see what we could make of it together...

Re: Comments vs. "Extract Code"

Posted By:   Stephen_McConnell  
Posted On:   Tuesday, December 16, 2003 10:35 AM

I think the answer truely lies in what you are comfortable with. If you have a lot of straight line code that is only used once.... then keep it in a single method.


I have been a long time firm believer in the concept that you should be able to see all the statements in a method in one editor window... But have run across some methods that I didn't do that with. They were just long lists of code with no logic in them.


But, if you can extract code into functional groups, then sometimes that is best.


There is no "Dogma" on how to refactor your code. If you are simplifying the reading and understanding of your code... Extract... if you are just extracting to keep smaller chuncks, then don't and comment your "logical/functional" groups of code.


Does this make sense... It's the guidelines I follow... and I also don't fall on my sword on these types of things if someone disagrees with me...


Stephen McConnell

About | Sitemap | Contact