if文での可読性の高いコード:論理演算篇

この記事でいいたいこと
  • if文の論理演算が多いときは改行をいれると読みやすい
  • 論理演算では否定は使わないほうが読みやすい
  • and/orは混在していないほうが読みやすい

それでは本文です。

読んでいるとif文でつまづく

条件分岐であるif文は可読性が落ちやすいポイントです。

良いプログラムというのは何千行もあるプログラムではなく、

数十行で収まるものだという意見があります。

そのような短いコードを読むときはすんなり頭に入って、

気持ちよくコードをよむことができます。

そういうコードに出会いたいですし、書きたいものです。

しかし、現実は短いコードだけで構成されているわけではありません。

数千行コードとか普通にあって、ふとこんなコードが出てきます。

if((temp_flag == false && stock >= sale_number && sale_start_time < now && !(sale_stop_time < now)) || ignore_flag == true){
    //処理
}

(ツッコミどころはありますがサンプルコードです)

条件式に慣れている方であれば読めると思います。

慣れていないと、、、

いや、慣れていたとしてもイライラしてしまうかもしれません。

当然それは可読性が低いことを意味します。

論理構造が見えづらい

そこに論理演算を重ねられると苦手な人は「()」の位置や、「&&」と「||」の数に辟易します。

加えて単純に一行に詰め込んでしまうと、どこまでがひと塊なのかが見えづらいです。

そこで「()」や論理演算子を意識して改行しておくといくらか可読性が上がります。

if((temp_flag == false
 && stock >= sale_number
 && sale_start_time < now
 && !(sale_stop_time < now)
) || ignore_flag == true){
    //処理
}

論理演算の否定は少ないほうがよい

論理演算で否定を意味する 「!」や「not」があるということも負荷をかけます。

算数のベン図とか否定が入るとちょっと面倒くさかったイメージありませんか?

色塗りを反転させたりした記憶があります。

懐かしい。

プログラムは必ずしも読みやすいように書かれていないことが多いです。

そこに「否定」があると反転させるという作業を必要とするので、

脳内のメモリを消費してしまいます。

ですので極力避けたほうが可読性が上がるでしょう。

コードを製造しているときは、ちょっと条件反転させるのに一文字打つだけですので「!」は使い勝手がいいんですよね。

ですが後から読む人のことを考えて我慢です。

and/orが混在していると可読性が落ちる

andで論理演算しているときは条件が厳しくなっていくのでif文でtrueになる対象が減っていくイメージです。

逆にorで論理演算しているときは条件がゆるくなっていくので対象が増えていくイメージになります。

数字に強い方でなければが混在すると暗算が追い付かないことないですか?

11-30+2-9+55-143 = ???? (暗算できる方がうらやましい)

厳密に論理演算と足し算引き算は違います。

ただ、増減が混在すると難しくなるという点では共通ではないでしょうか。

そう考えると一つのif文を構成する演算子の種類は片方だけが望ましいです。

私の経験にはなりますが、機能の特性上どうしてもand,orが混在してしまう場面をいくつか経験しています。

そういった場合は、前述にありますが、改行をいれることで論理構造を見えやすくしてあげると良いですね。

まとめ

  • if文の論理演算が多いときは改行をいれると読みやすい
  • 論理演算では否定は使わないほうが読みやすい
  • and/orは混在していないほうが読みやすい

if文において可読性と論理演算に着目して挙げてみました。

いかがでしょうか。

if文で論理演算を読みないと、これまで読んできたコードすべて吹き飛びます。

if文を読み終えたとき

「なんでこのコード読んでんだっけ?」

みたいに時間がもどります・・・

サンプルにさらっと紛れ込ませましたが

「temp_flag」のようなニュアンスで書かれていて

直で読むなら一時フラグですが、

当然のごとく「なんの一時フラグ?」となります。

「temp_flag」という命名もまた、

可読性を低下させています。

この問題については別の機会に言及しようと思います。