trueにすべきかfalseにすべきか

Question

if文の条件などに使われる真偽値は、trueとfalseどちらで統一すべきでしょうか。

Comments

[ozwk]

状況がよくわからないので「true」の場合と「false」の場合のコード例をお願いします

Answer 1

if文の中は当然trueとfalseの両方が発生するので「統一」するものではないですね。
ですので、下記の前者で統一すべきか？ 後者で統一すべきか？との質問と理解しました。
外していたらすいません。

if (今日は晴れ) {
    // 晴れ処理
} else {
    // 晴れでない時の処理
}

if (今日は晴れでない) {
    // 晴れでない時の処理
} else {
    // 晴れ処理
}

私は原則として前者で統一しようと努力してます。
「晴れ処理」がなく「晴れでない時の処理」だけの時は、後者を使います。
他に、他の処理との絡みで処理の順序を合わせたい等の特殊事情があれば後者を使うこともあります。

あ、間違って条件を逆に書いてしまい、後からヒックリ返した時は後者になってしまうことも結構あります。可読性が低下するのであまり良くないのですが、一度動作確認できた条件文はあまり触りたくないのでつい。

Comments

[KiyoshiMotoki]

私も、職場の上司に
「原則、条件式は肯定文で書け。
　その方が理解しやすいから」
と指導していただきました。

「否定文より肯定文の方が理解しやすい」
というのは、心理学で実証されているようですね。
http://pweb.sophia.ac.jp/c-michim/RM3C10.pdf
http://web.stanford.edu/~clark/1970s/Clark.Chase.comparing.72.pdf
2つ目のリンクは、私は読む気にはなりませんがw

[Chironian]

> 「否定文より肯定文の方が理解しやすい」
> というのは、心理学で実証されているようですね。
なるほど。

英語圏の人が「それは２重否定だからよくない」と書いているのを見たことが有ります。確かに「晴れでなければ◯◯しよう」、「晴れでないわけでなければ✕✕しよう」では遥かに前者の方が分かりやすいです。
否定から始めると、次は２重否定になるから、混乱しやすいですね。

Answer 2

例えば、Trueで統一した結果、THEN節には処理がなく、ELSE節にのみ処理が存在するという結果になってしまったら、どう考えますか？
Trueに統一することで、下記のようなコードが頻発するようだと、特に統一のルールなど設けずに、ケースバイケースで良いのではないかと思います。

if (条件式){
  // THEN節の処理無し
}
else {
  i = a+b;
}

Answer 3

自分なら「何を判断したくて条件分を記述しているのか」がわかりやすいことを第一に考えます。
例えば、エラーの時に中断したい場合、

If isError = True Then
  'エラー時
  Exit Sub
Else
  '正常時
End If

という感じになると思います。

同じ内容でも、エラーが発生していなければ実行したい、という場合であれば

If isError = False Then
  '正常時の処理
Else
  'エラー時
  Exit Sub
End If

とすると思います。

もちろんどちらの条件も同程度という場合もあります。
そういう場合はTrueを優先して記述することが多いですが、If～Else～EndIfの関係が掴みやすくなるよう処理内容が少ないものを先に記述する場合もあります。
ここは人によって好みが分かれるかもしれません。

If isError = False Then
  'エラー処理
  Exit Sub
Else
  '正常処理
  ・・・
  '(１画面に収まらないくらい長いコード)
  ・・・
End If

---

本題からは少しずれてしまいますが、関数の戻り値についてはより注意深く戻り値を検討しています。

例えばチェック関数の戻り値の場合、基本的にはチェック結果が正常値の場合にTrue、異常値があった場合にFalseとするようにしています。

If CheckInputValue() = False Then
  '異常値の場合
Else
  '正常値の場合
End If

となるからです。

ただし、関数名をIsErrorとかFindErrorValueのようにつけた場合は、異常値をTrueとしたほうが自然になります。

大事なのは、何も知らない人がソースを読んだときにできるだけ自然な解釈で読めるよう心がけることだと思います。

Answer 4

そもそも、なぜ統一する必要があるのでしょうか？
どういう理由で統一する必要があるのか疑問に感じます。
臨機応変、統一する必要は特に無いと思います。

Answer 5

すでにベストアンサーが決まっているようですが、私の場合は次の順で選びます。

##条件チェックする対象の値や論理表現が主（それに合わせてif文条件式を書く）
条件チェック対象の変数やオブジェクトとロジックの表現仕様が先であり、IF文内の表現の肯定否定はそれに合わせた後付けです。

分岐の際に、条件チェックする対象（オブジェクトなど）のプロパティやメソッド戻り値の表現が主で、IF文内の条件式はあくまでその表現と実現したいロジックとを合わせる従の存在です。

ご質問は、IF文で利用する想定の、状態を表現するBoolean変数を抜き出すとしたらどちらにするかとの趣旨なのかな？と解釈しました。

//開いてたら、閉じる。その１
bool isClosed = ...;
if(!isClosed)
{
  Close();
}

//開いてたら、閉じる。その２
bool isOpen = ...;
if(isOpen)
{
  Close();
}

上記をふまえて、IF文の記述について言及させていただくと...私は基本的に

1. IF文条件式のコードを読んで、意味がわかりやすいほうにする。

var fs = File.Open();
...
if((fs != null) && (!fs.Closed))
{
// fsがnullではなくかつ、閉じられていなければ（fs.ClosedプロパティがFalseであれば）、閉じる（fs.Closeメソッドを呼ぶ）。 -> 閉じてほしいんだな。
 fs.Close();
}

2. コード全体が簡素になるほうにしてコードの見通しを良くする

例えばサブルーチンやメソッドを記述している場合、コードが短くなるように、自ルーチン・メソッド内で処理する必要のない条件を先に抽出し、さっさと return してしまいます。 そのあとも、短いコードになるほうを真条件にしてメソッド内の上方に書くことで、自ルーチン・メソッドの可読性・ロジックの見通しやすさが上がります。あるロジックの結果に従属するロジックがあれば、当然その前後関係は保ちますが...

bool Func(string path, int numOfCopy)
{
  // 引数チェック
  if(String.IsNullOrEmpty(path))
  {
    return false;
  }
  if(!System.IO.File.Exists(path))
  {
    return false;
  }
  if(numOfCopy < 1)
  {
    return false;
  }
  // 本処理
  int idx = 1;
  for(...
  ...
  ...
  ...
  return true;
}

Answer 6

どちらでも構わないと思います。
事前にわかるのであれば、分岐の確率が多い方にしたらいいと思います。

Answer 7

今日は暖かくないか？みたいなことまで要求されるなら次元は違うかもしれませんが、
文字列が数値か？って問合せなら数値なら true、そうでなければ false 程度で良いのでは？