不等号の向きについて、リーダブルコードとコードコンプリートで言ってることが違っていて、
(そして個人的にはコードコンプリート派なので)その辺り解説してみます。
リーダブルコードの主張
「左に主眼を置いているものがあるべき」というのがリーダブルコードの主張です。
左側 右側 「調査対象」の式。変化する。 「比較対象」の式。あまり変化しない。
(「7.1 条件式の引数の並び順」より)
わかりやすさの根拠としては、「英語の用法と合っている」が挙げられています。
コードコンプリートの主張
「数直線の並びと合わせるべき」というのがコードコンプリートの主張です。
言い方を変えると、「<だけを使って>は使わない」ということになります。
数値の評価は、数直線上の点を順にたどるような構成にする。
(中略)
逆に、iの値がMIN_ELEMENTSよりも大きいはずであれば、次のような評価を使用することになる。
while ( MIN_ELEMENTS < i ) ...
(上巻「19.1.6 数値を含んでいる式は数直線の順番に並べる」より)
具体例で比較
2つの主張で違いが出るのが「主眼を置いているもの(変化するもの)が比較対象より大きい」という条件(下限の条件)の時です。
例えば、「xが0より大きい」という条件を書くと以下のようになります。
// リーダブルコード方式
if(x > 0) {
...
// コードコンプリート方式
if(0 < x) {
...
リーダブルコード方式しか見てこなかった人は後者は違和感があるかもしれません。
(算数・数学をやっていた時と同じように、仕様の整理やロジックの検討時に数直線を使って図示していれば、その図上の位置関係とコード上の位置関係が一致するのでこれはこれでわかりやすいと思うのですが)
一方、コードコンプリート方式で一番恩恵を得られるのが「上限下限の両方の条件がある場合」です。
例えば、「xが0より大きく、かつ10より小さい」という条件を書くと以下のようになります。
// リーダブルコード方式
if (x > 0 && x < 10) {
...
// コードコンプリート方式
if (0 < x && x < 10) {
...
Pythonなら0 < x < 10と書ける(そういう構文がわざわざ用意されている)ことを思えば、コードコンプリート方式の方が読みやすいと思う人が多いのではないかと推察します。
(というかPython書く人はみんなコードコンプリート方式なんですかね……？)
このパターンでコードコンプリート方式の方を採用するなら、前述の「下限の条件だけ」のパターンでもこれに合わせておいたほうが、仕様が変わったりリファクタリングで上限の条件が増えた場合に都合が良いです。
あとは単に「<だけ使って>は使わない」の方がルールとして単純であり、人が理解・判断するのも機械に判断させるのも容易であるとも考えられます。
ということで、今までリーダブルコード方式しか知らなかった方は、コードコンプリート方式の存在も気に留めておいていただければと思います。
同志
比較演算子「>」「>=」を使わなければ QOL が上昇する - Qiita
追記
この記事を書いてから、いくつかQiita内の記事やコメントで引用していただきました。
(ありがとうございます！)
それらのやりとりを見ていてなるほど、と思ったものがあったので、ここで紹介させていただきます。
偏見かもしれませんが、理系の人はコードコンプリート方式、文系の人はリーダブルコード方式を好む傾向にあるような気もします。
(@alt_yamamotoさん 2021-05-14 09:31 より)
コードを読むときに、脳が計算式だと認識したのか、文章だと認識したのかによって、
どっちが読みやすいかが変わってきそうですね。数値の比較であることがわかりきっている状況であれば、コードコンプリート方式のほうが読みやすそうです。
(@H40831さん 2021-05-14 10:08 より)
確かに自分は理系だし、大小比較は完全に数式として認識してますね。
あと個人的にはいわゆる「左右盲」なのでそれも大きい気はしています。