滅入るんるん

何か書きます

トップ > C# > if(flag == true)はありなのか？なしなのか？

if(flag == true)はありなのか？なしなのか？

C# Kotlin Java プログラミング

最近バズってるようなので便乗
ちなみに元ネタはこちらだとおもいます→qiita - Javaではif (flag == true)というコードを書いてはいけない

※真偽値としてのネーミングとしてflagはナシだろ～～ｗという話はナシでお願いします
※以下flag変数は真偽値とします

結論から言うと純粋な真偽値の場合はif(flag == true)、if(flag == false)はナシです

まず、最初に前提を整理します

  • if文は真偽値(true or false)で判定しなければならない
  • Javaではboolean
  • KotlinではBoolean
  • C#ではbool
話の簡素化のために整えておかないといけないこともあります
  • JavaではBooleanのことは考えない(理由は省略)(ボクシング次第では考えていいかも)
  • KotlinではBoolean?のことは考えない
    • nullableな場合はtrue or false or nullなので
  • C#ではbool?のことは考えない
    • nullableな場合はtrue or false or nullなので
前提を整理し終わったので、if(flag == true)はアリなのかナシなのか考えていきましょう。
おそらくif(flag == true)論争では2つのパターン(==演算子で比較するかどうか)に派閥分けされていますが、ここでは3つのパターンに分けます

1つ目のパターン：==演算子で比較する

// true比較の場合
if(flag == true)

// false比較の場合
if(flag == false)

はい、もっともナシなパターンです(理由は後述)。

ナシと言われる理由は前提を振り返ればわかりますがif文の中では最終的に真偽値であればよいのですがflagはそもそも真偽値です。わざわざtrueと==比較して真偽値にする必要はありません。わざわざ==比較することは理論上はパフォーマンスが落ちます。

このパターンがなくならない理由は可読性がまぁまぁいいことです。
冗長であろうがパフォーマンスが理論上悪かろうが可読性があれば正義です(そういう考えもできる)。

自分も昔はこのパターンな書き方を多用していましたが後述の理由によって今はしません(少なくとも意識してはしてないはず)。

2つ目のパターン：否定演算子!を使う

// true比較の場合
if(flag)

// false比較の場合
if(!flag)

記述量が最も少ない書き方です。

ナシではないですがアリでもないです(少なくとも自分の中では)。
1つ目のパターンと比較すると==比較しないことにより冗長なとこと理論上パフォーマンスが落ちることを改善できます。

それならこのパターンでこの論争は終結じゃん、、、とはならず。見ればすぐわかるのですが!演算子がとても見ずらい。フォント次第ではどうにかなるのだろうが!だけでかでかと表示するフォントもいかがなものかと。trueの場合とfalseの場合で1文字しか違うということから決定的に可読性が低いです。



この2つのパターンどちらも選べないというそこのあなた、3つ目のパターンによって解決♪解決♪です

3つ目のパターン：falseのときだけ==演算子で比較する

// true比較の場合
if(flag)

// false比較の場合
if(flag == false)

はい、いいとこどりのようなパターンです。そして個人的な最適解です。

trueの場合は==演算子を使わないことによって冗長な点と理論上パフォーマンスが悪くなる点を改善でき、falseの場合には==演算子で比較してあげることによって可読性が保てます。てか、可読性が最も上がります。

なぜかというとtrueとfalseの場合で7文字(半角スペース入れたら9文字)違うんですよね。これだけ違えば見間違えることはありませんし、4 or 5文字違う1つ目のパターンより可読性はいいです。ええ、それはもう決定的に可読性がいいと言っていいほどに。

ですので、個人的にはこの3つ目のパターン推しです。そして、3つ目のパターンがあることによって1つ目のパターンは決定的にあり得ないと言い切っていいと思います。

ちなみにfalseの場合、理論上パフォーマンスが落ちるではないかという話になりますがパフォーマンスが落ちるのは理論上です。このあたりのレベルだとコンパイラーによる最適化を期待することもできます。

代入演算子=と書き間違えるのではないかという話に関しては、それはもうどうしようもないですとしか言いようがない。。。nullと比較するときどうするんだよ、となりますからif文で代入演算子使える言語ではこれに関しては気をつけるしかないかと思います。

さいごに

前提条件でKotlinの場合を触れましたがKotlinではnot()関数使って、どうぞ。
C#で拡張メソッドとしてNot()を定義するのはどうかなとつくづく思いますが、パフォーマンスどうなんですかね。

追記：気になったので調べてみた [C#]拡張メソッドでboolにNot()を生やすとどの程度パフォーマンスに影響があるのか調べてみた

© 2018 meil.