検討:
if (something) {
// Code...
}
CodeRushをインストールした状態で、次のことをお勧めします。
if (!something) {
return;
}
// Code...
誰かがこれがどのように優れているか説明できますか?確かに、これまでのところ何のメリットもありません。
検討:
if (something) {
// Code...
}
CodeRushをインストールした状態で、次のことをお勧めします。
if (!something) {
return;
}
// Code...
誰かがこれがどのように優れているか説明できますか?確かに、これまでのところ何のメリットもありません。
あなたがそれを提示したように、孤立している-利益はありません。しかし、mark4oは正しいです:それはネストが少なく、4レベルのネストと言っても非常に明確になります。
public void foo() {
if (a)
if (b)
if (c)
if (d)
doSomething();
}
対
public void foo() {
if (!a)
return;
if (!b)
return;
if (!c)
return;
if (!d)
return;
doSomething();
}
このような早期の返品により、読みやすさが向上します。
場合によっては、メソッドの開始時にすべての入力を検証し、何かが正しくない場合はベイルアウトする方がクリーンです。入力が適切であると確信するまで、より具体的なことを連続してチェックする一連の単一レベルのチェックを行うことができます。そうすれば、メソッドの残りの部分は記述がはるかに簡単になり、ネストされた条件文が少なくなる傾向があります。
ネストのレベルが1つ少なくなります。
これは、保守性を目的とした従来のリファクタリングです。見る:
http://www.refactoring.com/catalog/replaceNestedConditionalWithGuardClauses.html
1つの条件で、それは大きな改善ではありません。しかし、それは「フェイルファスト」の原則に従っており、条件がたくさんあるときに本当にメリットに気づき始めます。関数に単一の出口点を持たせることを通常推奨する「構造化プログラミング」で育った場合、不自然に思えるかもしれませんが、3レベル以上のネストされた条件を持つコードをデバッグしようとしたことがあれば、理解し始めるでしょう。それ。
これを使用して、コードを読みやすくすることができます(ネストを少なくすることにより)。良い例についてはここを、メリットについての良い議論についてはここを参照してください。
この種のパターンは、一般的に次の置換に使用されます。
void SomeMethod()
{
if (condition_1)
{
if (condition_2)
{
if (condition_3)
{
// code
}
}
}
}
と:
void SomeMethod()
{
if (!condition_1) { return; }
if (!condition_2) { return; }
if (!condition_3) { return; }
// code
}
これは目にははるかに簡単です。
CodeRushがそれを推奨しているとは思いません---むしろオプションとして提供しているだけです。
IMO、それは例外的なケースであるかどうsomething
かによって異なります。!something
発生した場合に大量のコードがある場合は、条件をsomething
使用!something
する方が読みやすさと潜在的なネストの削減に適しています。
さて、それをこのように見てください(私は例としてphpを使用します):
フォームに入力して、次のページに移動します:validate.php
例1:
<?php
if (valid_data($_POST['username'])) {
if (valid_data($_POST['password'])) {
login();
} else {
die();
}
} else {
die();
}
?>
vs
<?php
if (!valid_data($_POST['username'])) {
die();
}
if (!valid_data($_POST['password'])) {
die();
}
login();
?>
どちらがより良く、維持しやすいですか?これは2つのことを検証しているだけであることを忘れないでください。これを登録ページなどで想像してみてください。
私は大学の仕事でマークを失ったことを非常にはっきりと覚えています。
if (!something) {
return;
}
// Code...
フォーマット。私の講師は、関数内に複数の出口点を設けることは悪い習慣であると認識しました。私はそれがナッツであり、20年以上のコンピュータープログラミングの後であると思いました、私はまだそうします。
公平を期すために、彼は共通語がCであり、関数がページ長でネストされた条件でいっぱいで、何が起こっているのかを追跡するのが難しい時代に住んでいました。
しかし、当時も今も、シンプルさが重要です。関数を小さく保ち、コメントを付けることが、読みやすく保守しやすいものにするための最良の方法です。