if文の条件式を
// 省略した書き方
if(a) {
// ...
}
ではなく、
// 省略しない書き方
if(a === true) {
// ...
}
と書くようにした話です。
※ここでは主に、JavaScriptを想定して説明します。
他の言語等にも共通する話ですが、各値を条件式に入れた時にTrueとして扱われるのか、はたまたFalseなのか厳密な判定はきちんと調べていないので、その点ご了承ください。
これまでは
もともとプログラミング初心者の頃は下側の省略しない書き方をしていました。
ですが、各言語の理解が深まる内に、0やundefinedやnullを条件式として評価した時に、falseとして扱われる事を知ってからは上側の省略した書き方を使うようになり、最近までこの書き方を多用していました。
省略した書き方のメリット
コードが短くなる
条件式が短くなって、すっきりしますね。
(これくらい？)
省略した書き方のデメリット
どんな値が来るか分かりづらい
省略した書き方をやめた理由として、正直これが大きいです。
このif文を見た時、変数aが論理値なのか、数値なのか、文字列なのか分からないですよね。
例として、変数aには文字列が入る可能性があって、何も入らなかった場合(undefined)にとあるの処理を行いたい時、以下のように書けます。
if(!a) {
// とある処理
}
ですが、これだけ読むとaには何が入り、どういった時にこの処理を通したいのか、コードを書いた人の意図が推測しづらいです。
JavaScriptの場合、上のコードのだと変数aが以下の値でも処理が通ります。
- false
- 0
- null
- undefined
- "" (空文字)
もちろんJava等の静的型付けの言語であれば定義を読めば型は分かりますが、それでも定義までさかのぼる必要があります。
また、JavaScript等の動的型付けの言語は型の定義が無いので、その変数に代入している箇所を探す必要があり、かなり手間です。
想定外の値を通してしまう
省略した書き方だと、仮に「変数aには論理値が入ると想定していたのに文字列が入っていた」場合、処理が通ってしまうことがあります。
（論理値を想定していたのに文字列が入ることは少ないかもしれませんが、undefinedのままだったという事は多いと思います。）
省略しない書き方に変えた結果
上記のデメリットがだいぶん軽減されました。
たとえば以下のように、そこを読むだけで変数aにどんな値が入ることを想定しているのかが分かりやすい。
if(a === "hoge") {
// ...
}
// なるほど、変数aには「文字列」が入るのか...
if(a === 1) {
// ...
}
// なるほど、変数aには「数値」が入るのか...
if(a === false) {
// ...
}
// なるほど、変数aには「論理値」が入るのか...
当然、変数にaなんて分かりづらい名前を付けるから分かりづらいのであって、実際はもっと分かりやすい名前を付けると思います。
しっかり命名規則に則った分かりやすい変数名を使えば、ある程度変数の中身を推測することはできますが、それに加えて上記のように書くことで、より読みやすいコードになると思います。
まとめ
if文には、変数をつっこむだけの雑な条件式をやめると、読みやすいコードになるかも？という話でした。
自分が書いたコードでさえ、数ヶ月経って読むと分からなくなるので、省略せずに書いてあるとだいぶラク。
この書き方にしてからコードを読んで理解するスピードが上がったと思います。
もし、「省略しない書き方にはこんなデメリットがあるぞ」などありましたら、コメントにて教えてください。