私は次のプラクティスを使用していることに気づきましたが、それを使用するたびに私の中で何かが縮みます. 基本的に、実際の作業を行う必要があるかどうかを判断するためのパラメーターの前提条件テストです。
public static void doSomething(List<String> things)
{
if(things == null || things.size() <= 0)
return;
//...snip... do actual work
}
私は次のプラクティスを使用していることに気づきましたが、それを使用するたびに私の中で何かが縮みます. 基本的に、実際の作業を行う必要があるかどうかを判断するためのパラメーターの前提条件テストです。
public static void doSomething(List<String> things)
{
if(things == null || things.size() <= 0)
return;
//...snip... do actual work
}
できるだけ早い機会に戻ることをお勧めします。
そうすれば、最小量のコードが実行および評価されます。
実行されないコードがエラーになることはありません。
さらに、適用されないすべてのケースに対処する必要がないため、関数が読みやすくなります。
次のコードを比較してください
private Date someMethod(Boolean test) {
Date result;
if (null == test) {
result = null
} else {
result = test ? something : other;
}
return result;
}
対
private Date someMethod(Boolean test) {
if (null == test) {
return null
}
return test ? something : other;
}
2 番目のものは短く、else を必要とせず、temp 変数も必要としません。
Java では、return
ステートメントは関数をすぐに終了することに注意してください。他の言語 (Pascal など) では、ほぼ同等のコードresult:= something;
は返されません。
このため、Java メソッドの多くのポイントで戻るのが通例です。
これを呼び出すbad practice
ことは、その特定の列車が Java の駅を離れて久しいという事実を無視しています。
とにかく関数内の多くのポイントで関数を終了する場合は、できるだけ早い機会に終了することをお勧めします
それはスタイルと個人的な好みの問題です。何も問題はありません。
私の理解の範囲では -いいえ。
デバッグを容易にするために、サブルーチン、メソッド、または関数の戻り/終了ポイントは 1 つだけにする必要があります。
このようなアプローチでは、プログラムが長くなり、読みにくくなる可能性がありますが、デバッグ中に出口にブレークポイントを配置して、返されるものの状態を常に確認できます。たとえば、すべてのローカル変数の状態をログに記録できます。これは、トラブルシューティングに非常に役立つ場合があります。
2 つの「学校」があるようです。1 つは「できるだけ早く戻る」と言い、もう 1 つは「プログラムには 1 つの戻り/終了ポイントしかない」と言っています。
私は最初のものの支持者ですが、実際には時間を節約するために2番目のものに従うこともあります.
また、例外についても忘れないでください。多くの場合、メソッドから早く戻らなければならないという事実は、例外的な状況にあることを意味します。あなたの例では、例外をスローする方が適切だと思います。
本質的に悪いことは何もありませんが、それがあなたをうんざりさせるなら、IllegalArgumentException
代わりに投げることができます。場合によっては、それがより正確です。ただし、次のように呼び出すと、次のように見える一連のコードが生成される可能性がありますdoSomething
。
try {
doSomething(myList);
} catch (IllegalArgumentException e) {}
PMD はそう考えているようで、常にメソッドを最後まで実行する必要があると考えていますが、特定の迅速な健全性チェックのために、私はまだ時期尚早のreturn
ステートメントを使用しています。
メソッドの可読性が少し損なわれますが、場合によってはif
、すべてのケースでメソッドを最後まで実行するために、さらに別のステートメントまたはその他の手段を追加するよりも優れている場合があります。
この質問には正解はなく、好みの問題です。
上記の特定の例では、前提条件を強制するより良い方法があるかもしれませんが、複数の早期復帰の一般的なパターンは、関数型プログラミングのガードに似ていると考えています。
個人的には、このスタイルに問題はありません。よりクリーンなコードになると思います。単一の出口点を持つようにすべてをねじ曲げようとすると、冗長性が増し、読みやすさが低下する可能性があります。
それは良い習慣です。それでは、良い仕事を続けてください。
メソッドの「return」を避けたい場合:独自のExceptionのサブクラスを使用して、メソッドの呼び出しでそれを処理できますか?
例えば :
public static void doSomething(List<String> things) throws MyExceptionIfThingsIsEmpty {
if(things == null || things.size() <= 0)
throw new MyExceptionIfThingsIsEmpty(1, "Error, the list is empty !");
//...snip... do actual work
}
編集:「return」ステートメントを使用したくない場合は、if()で反対のことを行うことができます:
if(things != null && things.size() > 0)
// do your things
何も問題はありません。個人的には、elseステートメントを使用して残りの関数を実行し、自然に戻るようにします。
Java のグッド プラクティスでは、できるだけ多くの場合、return ステートメントは一意であり、メソッドの最後に記述する必要があります。返すものを制御するには、変数を使用します。ただし、使用する例のように、void メソッドから戻るには、そのような目的でのみ使用される中間メソッドでチェックを実行します。とにかく、これをあまり深刻にcontinue
考えないでください。 Java の適切な実践に従って、 like のようなキーワードを使用するべきではありませんが、それらはスコープ内にあります。