これは非常に単純化された例です。これは必ずしも言語固有の質問ではありません。関数を作成できる他の多くの方法、およびそれに加えられる変更を無視してください。。色はユニークなタイプです
string CanLeaveWithoutUmbrella()
{
if(sky.Color.Equals(Color.Blue))
{
return "Yes you can";
}
else
{
return "No you can't";
}
}
私が出会った多くの人々、ReSharper、およびこの男（コメントから、しばらくの間これを尋ねようとしていることを思い出した）は、コードをリファクタリングして、elseこれを残すブロックを削除することをお勧めします。
（私は大多数が言ったことを思い出せない、そうでなければ尋ねなかったかもしれない）
string CanLeaveWithoutUmbrella()
{
if(sky.Color.Equals(Color.Blue))
{
return "Yes you can";
}
return "No you can't";
}
質問：elseブロックを含めないことで複雑さが増しますか？
私はelse、両方のブロックのコードが直接関係しているという事実を述べることにより、意図がより直接的に述べられているという印象を受けています。
さらに、特に後日コードを変更した後は、ロジックの微妙な間違いを防ぐことができます。
私の単純化された例のこのバリエーションを取り上げます（orこれは意図的に単純化された例であるため、演算子を無視します）。
bool CanLeaveWithoutUmbrella()
{
if(sky.Color != Color.Blue)
{
return false;
}
return true;
}
誰かがif、最初の条件が自分の条件に制約を設定していることをすぐに正しく認識せずに、最初の例の後に条件に基づいて新しいブロックを追加できるようになりました。
elseブロックが存在する場合、新しい条件を追加した人はelseブロックのコンテンツを移動するように強制されます（そして、何らかの理由でそれらをブロックすると、ヒューリスティックによりコードが到達不能であることが示されifます。 。
もちろん、特定の例がとにかく定義されるべき他の方法があり、そのすべてがその状況を防ぎますが、それは単なる例です。
私が与えた例の長さは、これの視覚的側面を歪めるかもしれないので、括弧までのスペースはメソッドの残りの部分にとって比較的重要でないと仮定します。
elseブロックの省略に同意し、ifブロックを使用して、ヌルチェック（またはその他のガード）などの後続のすべてのコードに対して論理的に満たす必要がある制約を適用する場合について言及するのを忘れました。
else句を書くときに読みやすいかもしれないことに同意します（私の好みでは、不必要な括弧を省くとさらに読みやすくなります。しかし、上記の場合return sky.Color == Color.Blue（if / elseなし）
