できるかぎりメソッドを短くしましょう。
ばかばかしいと思うぐらい、簡単な処理の数行のメソッドを目指すぐらいでちょうどいいと思います。
メソッドが長いと
（１）読む気がしない。
（２）モチベーションが下がり、機能を追加するとき、適当な箇所にコードを追加して、さらに長くなります。
（３）テストケースを書きにくい。
リーダブルコードの10.8 やりすぎの例がありますが、あれぐらいやったほうがいいと思います。別クラスにすれば、なおいいですね。
50行をこえたら
長すぎます。
長くなると、読みづらくなります。読みやすくするためには、リファクタして小さいメソッドに分ける必要があります。しかし長いメソッドにテストケースがないことが多く、安心してリファクタできないんですね。
Activity.onCreateやFragment.onCreateViewは長くなりがちです。findViewByIdしたり、setOnClickListenerすると、それだけで４行です。LayoutやViewごとにprivateメソッドに切り出しましょう。
コメントを書きたくなったとき
コメントを書くよりも、privateメソッドとして切り出してください。ばかばかしいと思うぐらい、簡単な処理のメソッドにしましょう。
コードはメンテしないと動かなくなりますが、コメントはメンテしなくても動作に影響しないので、コメントは放置されることが多いです。
それよりは、新たにメソッドとして切り出して、メソッド名と変数名に気を使ったほうが、後々読みやすいです。
for文の繰り返し本体
5行以上になったら、別メソッドに切り出することを考えましょう。
if文の条件式
複数の条件式を|| や && していたら、条件式まるごと、別メソッドに切り出しましょう。
if文の本体
5行以上になったら、別メソッドに切り出することを考えましょう。
変数名a1、a2を使っているとき
メソッド内でコピペしたときに、よくあります。ペースト先の変数名の終わりに 1 や 2 をつけてしまいがちです。
コードが動作することを確認したら、リファクタして、別のメソッドに切り出しましょう。
デバッグするとき、まとめてコメントアウトする複数行
不具合の原因を追跡するとき、複数行をコメントアウトしては実行、別の複数行をコメントアウトしては実行することがあります。この「複数行」は意味のある可能性が高く、別メソッドに切り出したほうがいいかもしれません。
別メソッドにしておくと、デバッグのとき、呼び出し元の１行をコメントアウトするだけですみます。
デバグ表示
いつのまにか、数行にわたって、Log.dを書いていることがあります。デバグのために重要ですが、本来のコードが目立つように、別メソッドにしましょう。さらに、オブジェクトのtoStringメソッドをオーバーライドできるかどうか検討してください。
