Kevin Rutherford, PhD, is a UK-based extreme programmer and agile software coach with over 30 years professional experience. He developed the Reek code-smell detector for Ruby and co-authored "Refactoring in Ruby". Kevin is a DZone MVB and is not an employee of DZone and has posted 14 posts at DZone. You can read more from them at their website. View Full User Profile

Why Shorter Methods Are Better

02.07.2013
| 6111 views |
  • submit to reddit

TL;DR
Longer methods are more likely to need to change when the application changes.

The Longer Story
Shorter methods protect my investment in the code, in a number of ways.

First: Testability. I expect there to be a correlation between method length (number of “statements”) and the number of (unit) test cases required to validate the method completely. In fact, as method size increases I expect the number of test cases to increase faster than linearly, in general. Thus, breaking a large method into smaller independent methods means I can test parts of my application’s behaviour independently of each other, and probably with fewer tests. All of which means I will have to invest less in creating and running the tests for a group of small methods, compared to the investment required in a large method.

Second: Cohesion. I expect there to be a strong correlation between method length and the number of unknown future requirements demanding that method to change. Thus, the investment I make in developing and testing a small method will be repaid countless times, because I will have fewer reasons in the future to break it open and undo what I did. Smaller methods are more likely to “stabilize out” and drop out of the application’s overall churn.

Third: Coupling (DRY). I expect that longer methods are more likely to duplicate the knowledge or logic found elsewhere in the same codebase. Which means, again, that the effort I invest in getting this (long) method correct could be lost if ever any of those duplicated pieces of knowledge has to change.

And finally: Understandability. A method that does very little is likely to require fewer mental gymnastics to fully understand, compared to a longer method. I am less likely to need to invest significant amounts of time on each occasion I encounter it.

The Open-Closed Principle says that we should endeavour to design our applications such that new features can be added without the need to change existing code — because that state protects the investment we’ve made in that existing, working code, and removes the risk of breaking it if we were to open it up and change it. Maybe it’s also worth thinking of the OCP as applying equally to methods.

 

Published at DZone with permission of Kevin Rutherford, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Caspar MacRae replied on Thu, 2013/02/07 - 7:30am

Good points, in addition to OCP I think SRP (Single Responsiblity Principle) can be applied at the method level too.

Mark Unknown replied on Thu, 2013/02/07 - 10:36am

Why longer methods are "better":

I can just use notepad (or some other text editor)

I don't have to open tons of files

I can see all the code in one place

I take a short term view of software development (meaning ignore pretty much everything in this post - http://java.dzone.com/articles/10-groups-software-quality)

:)

(note: I !=  me ;) )

Tayo Koleosho replied on Tue, 2013/02/12 - 9:40am in response to: Mark Unknown

 So no cohesion or encapsulation for ya huh? Just a chain of If statements? The link you posted is dead btw, could you repost?

Mark Unknown replied on Tue, 2013/02/12 - 6:34pm

Exactly. ;) 

FYI - my post was "humor" - the excuses or reasons i have heard. That is why i said " I != me" or "I is not equal to me." 

The "I can see all the code in one place" was taken from a story a friend told me about loooong ago when he was doing COBOL and tried to use procedures. One of the "more experienced" developers got mad because the code was not all in one place. 

Fyi - all you had to do to the link was remove the ")".  - http://java.dzone.com/articles/10-groups-software-quality  I must have had a cut/paste/typing error.


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.