How to convince your fellow developer to write short methods?
I'm sure you've seen your share of long methods—methods that run several hundred lines.
Some of us may have even written them, probably in those days before we gained our
wisdom to write better quality code.
Long methods are evil on several grounds:
- They're hard to understand
- They're hard to change
- They're hard to reuse
- They're hard to test
- They have low cohesion
- They may have high coupling
- They ten to be overly complex
Often programmers ask, how "long" is a long method? A method is too long if
- you have to scroll down to look at the complete method
- it takes several minutes to understand
- you can't easily write an automated test for it
- you can't state the one prominent purpose for the method
One easy way to address long methods is to use the so called Compose
Method Pattern.
Your methods then focuses on doing one thing and invokes other methods, all of which
are at the same level of abstraction. The result is shorter, easier to understand
methods
in your application.
You say, "OK, I get it, but what about my colleague who has a compulsive disorder
to
write very long methods, how do I convince that colleague?"
So you have tried to state the benefits, showed examples, and your colleague still
does not get it.
OK, I can suggest one final drastic measure.
On a Monday morning, when you go to work, your colleague asks how your weekend was.
You could say, "It was good, I took the kids to the movie on Saturday and went to
the park
on Sunday." That would be like using compose method pattern. You have stated your
activities
at one level of abstraction. If your colleague is interested in more details about
the movie or the
park, he or she can drill down into the details further asking you how the movie was,
and so on.
But, do not reply to that question that way. Instead say, "Over the weekend I got
into my car, started it,
drove 5 miles West, took a right turn, then a left turn, then drove another 10 miles,
..." Go at it for
several minutes until your colleague gets frustrated and interrupts you with "What's
wrong with you."
Now simply reply, "oh, I though I'll tell you how my weekend way like you write your
methods."
About Venkat Subramaniam
Dr. Venkat Subramaniam, founder of Agile Developer, Inc., has trained and mentored thousands of software developers in the US, Canada, Europe, and Asia. Venkat helps his clients effectively apply and succeed with agile practices on their software projects, and speaks frequently at international conferences and user groups. Venkat is also an adjunct faculty and teaches CS courses remotely at the University of Houston. He is author of ".NET Gotchas," coauthor of 2007 Jolt Productivity Award winning "Practices of an Agile Developer," author of "Programming Groovy: Dynamic Productivity for the Java Developer" and "Programming Scala: Tackle Multi-Core Complexity on the Java Virtual Machine" (Pragmatic Bookshelf).
More About Venkat »NFJS, the Magazine
December Issue Now AvailableBDD and REST
by Brian SlettenMocks and Stubs in Groovy Tests
by Kenneth KousenAlgorithms for Better Text Search Results
by John GriffinKnowns and Unknowns of Scrum and Agile
by Brian Tarbox