How to convince your fellow developer to write short methods?

Question

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 tend to be overly complex

How to convince your fellow developer to write short methods? (weapons are forbidden =)

question from agiledeveloper

Answer 1

Ask them to write unit tests for the methods.

Answer 2

That depends on your definitions of "short" and "long".

When I hear someone say "write short methods", I immediately react badly because I've encountered too much spaghetti written by people who think the ideal method is two lines long: One line to do the tiniest possible unit of work followed by one line to call another method. (You say long methods are evil because "they're hard to understand"? Try walking into a project where every trivial action generates a call stack 50 methods deep and trying to figure out which of those 50 layers is the one you need to change...)

On the other hand, if, by "short", you mean "self-contained and limited to a single conceptual function", then I'm all for it. But remember that this can't be measured simply by lines of code.

And, as tydok pointed out, you catch more flies with honey than vinegar. Try telling them why your way is good instead of why their way is bad. If you can do this without making any overt comparisons or references to them or their practices (unless they specifically ask how your ideas would relate to something they're doing), it'll work even better.

Answer 3

You made a list of drawbacks. Try to make a list of what you'll gain by using short methods. Concrete examples. Then try to convince him again.

Answer 4

I read this quote from somewhere:

Write your code as if the person who has to maintain it is a violent psycho, who knows where you live.