A Funny Java Flavoured Look at the World

Friday, September 29, 2006

Keep your methods small and focused

I read this the other day in the middle of an article talking about design. This is one of my favorite programming idioms because it makes reuse of the methods later so much easier. I ran into an example today and it's one of those examples that when you find you can reuse one of your methods you are pleased with yourself and thank your earlier self for helping you out now.

This is a very simple example but it basically involves using a template file and copying it and renaming. Last time I was doing this I had to copy a batch of files each file with a different extension. Instead of making a method which copied the files and mentioned their extension I wrote one method that did that but which called a smaller focused method . The method in question took folder to copy from, folder to copy to, filename, newFileName and extension. The method above just called it four times with different file extensions.

Now because I have a smaller focused method I can use that method today to copy some different files. I think this is one of the key points in being able to write reusable code, small focused methods which are not heavily coupled with other classes or are trying to do more than one task. I have heard this talked about as do one thing and do it well and linked to keep it simple. To put the above rambling in a more concise manner

1. Keep your methods small and focused.
2. Your method should do one task.

If you do the two above then you will probably be keeping the code simple anyway but splitting up potentially larger methods in smaller focused methods. As a bonus these methods are then easier and quicker to test and if a bug does sneak in then because the code is split up into smaller sections any code that needs to be fixed is isolated in it's own method.

2 Comments:

  • Great post! I am a strong proponent of keeping methods small. I think there are a few more important consequences of small methods besides the one you mentioned: testability and readability. It is not often I realize I already have the exact method I need; but very often I realize I have something close, and with a little refactoring, I have code that supports the old need and the new need.

    I wouldn't have these realizations if I could not easily read and understand my old code, and I wouldn't be able to do that without short methods.

    Also, you can't unit test code that's hiding in the middle of a big method. If it's not covered by unit tests, it's risky to refactor it; you might break the old code that's already using it.

    (Not to mention you'll end up with fewer bugs with well-tested code, and finding the bugs that remain is a hell of a lot easier with small methods that are well-tested).

    Cheers.

    By Blogger Ryan Cooper, at Fri Sept 29, 12:45:00 pm 2006  

  • A lot of people seem to like to put all of their code in one place so that they don't have to go looking for it, but a 2000-line method makes me crazy.

    You mentioned keeping the methods "focused" and doing "one task". That's basically the principle of cohesion, which has been around for about 30 years. Most people seem to be familiar with its counterpart, coupling, but they've forgotten about cohesion. You should be able to describe what a method does in a one-line sentence that does not contain the word "and".

    Another consideration that I take into account is cyclomatic complexity. I hate a method with 30 if statements, embedded 8-deep. Or loops within loops within loops. I limit myself to just one loop per method, and I try to have no more than two levels of if nesting. As a general rule, the content of a loop is coherent in itself and separating it out usually works nicely. The main exception is when the loop is updating a bunch of variables (as in a parser); Java doesn't make this easy to refactor out.

    With careful choice of method names, refactoring a big method into a bunch of smaller ones can result in a huge increase in readability. Choosing good method names isn't nearly as easy as it sounds, though. Or at least mine suck an awful lot of the time.

    By Blogger Doug, at Fri Sept 29, 09:42:00 pm 2006  

Post a Comment

<< Home