「if elif else」ステートメントが事実上テーブル形式ではないのはなぜですか？

if   i>0 : return sqrt(i)  
elif i==0: return 0  
else     : return 1j * sqrt(-i)

VS

if i>0:  
   return sqrt(i)  
elif i==0:  
   return 0  
else:  
   return 1j * sqrt(-i)  

上記の例を考えると、コードベースに最初のスタイルがほとんど見られない理由がわかりません。私には、コードを表形式に変換して、必要なものを明確に示します。最初の列は事実上無視できます。2列目は状態を示し、3列目は必要な出力を示します。少なくとも私には、簡単で読みやすいようです。それでも、この単純なケース/スイッチの状況は、拡張されたタブインデント形式で常に表示されます。何故ですか？人々は2番目の形式をより読みやすいと感じていますか？

これが問題になる唯一のケースは、コードが変更されて長くなる場合です。その場合、コードを長いインデントされた形式にリファクタリングすることは完全に合理的だと思います。いつもそれがいつも行われていた方法だからという理由だけで、誰もが2番目の方法でそれをしますか？悪魔の擁護者である私は、if / elseステートメントの複雑さに応じて2つの異なる形式を見つけて混乱する別の理由があると思いますか？どんな洞察もいただければ幸いです。

理由の1つは、人気のある言語を使用していないことです。

いくつかの反例：

ガードとパターン付きのHaskell：

sign x |  x >  0        =   1
       |  x == 0        =   0
       |  x <  0        =  -1

take  0     _           =  []
take  _     []          =  []
take  n     (x:xs)      =  x : take (n-1) xs

パターン付きのアーラン：

insert(X,Set) ->
    case lists:member(X,Set) of
        true  -> Set;
        false -> [X|Set]
    end.

Emacs lisp：

(pcase (get-return-code x)
  (`success       (message "Done!"))
  (`would-block   (message "Sorry, can't do it now"))
  (`read-only     (message "The shmliblick is read-only"))
  (`access-denied (message "You do not have the needed rights"))
  (code           (message "Unknown return code %S" code)))

一般に、テーブル形式は関数型言語（および一般的な式ベースの言語）で非常に人気がありますが、行を分割することは他の言語（主にステートメントベース）で最も人気があります。

より読みやすくなりました。いくつかの理由：

• ほとんどすべての言語がこの構文を使用しています（すべてではなく、ほとんど -あなたの例はPythonのようです）
• isanaeは、ほとんどのデバッガーは行ベース（ステートメントベースではない）であるというコメントで指摘しました。
• セミコロンまたはブレースをインライン化する必要がある場合、さらに見苦しくなります
• 上から下までよりスムーズに読み取ります
• 些細なreturnステートメント以外のものがある場合、恐ろしく読めないように見えます
  • 条件付きコードが視覚的に分離されなくなったため、コードをスキムすると、意味のあるインデント構文が失われます（Dan Neelyから）
  • これは、1行のifステートメントにアイテムをパッチ/追加し続けると特に悪いでしょう
• すべてのifチェックがほぼ同じ長さの場合にのみ読み取り可能です
• つまり、複雑なifステートメントを複数行のステートメントにフォーマットすることはできません。それらはonelinersでなければなりません
• 複数行を一緒に解析しようとせずに、行ごとに垂直に読み取るときにバグ/ logicflowに気付く可能性がはるかに高くなります
• 私たちの脳は、長くて水平なテキストよりもはるかに速く、狭くて背の高いテキストを読む

このいずれかを実行しようとすると、最終的に複数行のステートメントに書き換えられます。つまり、時間を無駄にしているだけです！

また、人々は必然的に次のようなものを追加します：

if i>0:  
   print('foobar')
   return sqrt(i)  
elif i==0:  
   return 0  
else:  
   return 1j * sqrt(-i)  

この形式が他の形式よりも優れていると判断するまで、これを頻繁に行う必要はありません。ああ、しかし、あなたはそれをすべて1行でインライン化できます！ エンダーランドは内側で死ぬ。

またはこれ：

if   i>0 : return sqrt(i)  
elif i==0 and bar==0: return 0  
else     : return 1j * sqrt(-i)

これは本当に、本当に迷惑です。このようなフォーマットを好む人はいません。

そして最後に、「タブ用のスペースの数」問題の聖戦を開始します。テーブル形式として画面上で完全にレンダリングされるものは、設定によっては私の画面上でレンダリングされない場合があります。

とにかく読みやすさはIDE設定に依存すべきではありません。

私は「コードは何度も読まれ、書かれた回数は少ないので、読みやすさが非常に重要です」と固く信じています。

他の人のコードを読むときに役立つ重要なことは、私の目が認識するように訓練されている「通常の」パターンに従うことです。インデントされたフォームを最も簡単に読むことができるのは、何度も見たことがあるため、ほとんど自動的に登録されるからです（私の側ではほとんど認知的努力は必要ありません）。それは「きれい」だからではなく、私が慣れている慣習に従っているからです。コンベンションは「より良い」ビート...

すでに述べた他の欠点に加えて、表形式のレイアウトは、バージョン管理マージの競合の確率を高め、手動の介入が必要です。

表形式で整列されたコードのブロックを再配置する必要がある場合、バージョン管理システムはこれらの各行が変更されたものとして扱います。

diff --git a/foo.rb b/foo.rb
index 40f7833..694d8fe 100644
--- a/foo.rb
+++ b/foo.rb
@@ -1,8 +1,8 @@
 class Foo

   def initialize(options)
-    @cached_metadata = options[:metadata]
-    @logger          = options[:logger]
+    @metadata = options[:metadata]
+    @logger   = options[:logger]
   end

 end

ここで、別のブランチで、プログラマーが整列されたコードのブロックに新しい行を追加したとします。

diff --git a/foo.rb b/foo.rb
index 40f7833..86648cb 100644
--- a/foo.rb
+++ b/foo.rb
@@ -3,6 +3,7 @@ class Foo
   def initialize(options)
     @cached_metadata = options[:metadata]
     @logger          = options[:logger]
+    @kittens         = options[:kittens]
   end

 end

そのブランチのマージは失敗します：

wayne@mercury:/tmp/foo$ git merge add_kittens
Auto-merging foo.rb
CONFLICT (content): Merge conflict in foo.rb
Automatic merge failed; fix conflicts and then commit the result.

変更中のコードが表の配置を使用していなかった場合、マージは自動的に成功していました。

（この答えは、コード内の表形式の整列を思いとどまらせる私自身の記事から「盗作された」）。

常に割り当てられた幅に収まる場合、表形式は非常に便利です。ただし、割り当てられた幅を超えるものがある場合、テーブルの一部が残りの部分と並んでいないか、テーブルの他のすべてのレイアウトを調整して長いアイテムに合うようにすることがしばしば必要になります。

表形式のデータを操作するように設計されたプログラムを使用してソースファイルを編集し、より小さいフォントサイズを使用して同じセル内で2行に分割するなど、過度に長いアイテムを処理できる場合、表形式を使用するのが理にかなっているより頻繁にフォーマットしますが、ほとんどのコンパイラーは、そのようなエディターがフォーマットを維持するために保存する必要がある種類のマークアップのないソースファイルを望んでいます。さまざまな量のインデントを使用し、他のレイアウトを持たない行を使用するのは、最良の場合は表形式よりも劣りますが、最悪の場合はほとんど問題が発生しません。

この種のことを特別な場合に提供する「switch」ステートメントがありますが、それはあなたが尋ねているものではないと思います。

テーブル形式のifステートメントを見てきましたが、それを価値のあるものにするためには多くの条件が必要です。3ステートメントが従来の形式で最適に表示される場合、20がある場合は、より明確にするためにフォーマットされた大きなブロックに表示する方がはるかに簡単です。

そして、ポイントがあります：明快さ。見やすいようになっている場合（および最初の例では：区切り文字がどこにあるかを簡単に確認できない場合）、状況に合わせてフォーマットします。それ以外の場合は、常に認識しやすいため、人々が期待するものに固執します。

あなたの表現が本当に簡単なら、ほとんどのプログラミング言語は？：分岐演算子を提供します：

return  ( i > 0  ) ? sqrt( i)
      : ( i == 0 ) ? 0
        /* else */ : 1j * sqrt( -i )

これは短い読みやすい表形式です。しかし、重要な部分は次のとおりです。「主要な」アクションが何であるか一目でわかります。これはreturnステートメントです！また、値は特定の条件によって決定されます。

一方、異なるコードを実行するブランチがある場合、これらのブロックをインデントする方がはるかに読みやすいと思います。これは、ifステートメントに応じて異なる「メジャー」アクションがあるためです。ある場合にはスローし、ある場合にはログに記録して戻るか、単に戻るだけです。ロジックに応じて異なるプログラムフローが存在するため、コードブロックはさまざまなブランチをカプセル化し、開発者にとってより目立つようにします（たとえば、プログラムフローを把握するための関数の高速読み取り）

if ( i > 0 )
{
    throw new InvalidInputException(...);
}
else if ( i == 0 )
{
    return 0;
}
else
{
    log( "Calculating sqrt" );
    return sqrt( -i );
}

すでにエンダーランドが言っているように、アクションとして「リターン」は1つしかなく、その「リターン」を条件の最後にタグ付けできると仮定しています。これがうまくいかない理由について、もう少し詳しく説明したいと思います。

私はあなたの好みの言語が何なのか分かりませんが、私は長い間Cでコーディングしています。初期コーディング中または後のメンテナンス中にエラーが発生しやすいコード構築を禁止することにより、いくつかの標準コーディングエラーを回避することを目的とした多くのコーディング標準があります。私はMISRA-Cに最も精通していますが、他にもあります。一般に、同じ言語で同じ問題に対処しているため、すべて同じようなルールを持っています。

コーディング標準がしばしば対処する一般的なエラーの1つは、この小さな落とし穴です。

if (x == 10)
    do_something();
    do_something_else();

これはあなたが思っていることをしません。xが10である場合に限りCに関しては、あなたは呼び出しdo_something()たが、その後do_something_else()呼び出さかかわらず、xの値の。「if」ステートメントの直後のアクションのみが条件付きです。これはコーダーが意図したものかもしれません。その場合、メンテナーにとって潜在的なpotentialがあります。または、コーダーが意図したものではない可能性があります。その場合、バグがあります。これは人気のあるインタビューの質問です。

コーディング標準の解決策は、単一行であっても、すべての条件付きアクションを中括弧で囲むことです。今すぐ

if (x == 10)
{
    do_something();
    do_something_else();
}

または

if (x == 10)
{
    do_something();
}
do_something_else();

そして今では正しく動作し、メンテナーにとって明らかです。

これは、テーブルスタイルの形式とは完全に互換性がないことに気付くでしょう。

他の言語（Pythonなど）はこの問題を見て、コーダーがレイアウトを明確にするために空白を使用しているため、ブレースの代わりに空白を使用することをお勧めします。だからPythonでは、

if x == 10:
    do_something()
    do_something_else()

両方の呼び出しを行い、x == 10 do_something()をdo_something_else()条件としますが、

if x == 10:
    do_something()
do_something_else()

は、do_something()x のみを条件とし、do_something_else()常に呼び出されることを意味します。

これは有効な概念であり、いくつかの言語で使用されています。（最初にOccam2で見たのは昔のことです。）でも、テーブルスタイルの形式が言語と互換性がないことは簡単にわかります。

表形式のレイアウトは、いくつかの限られた場合に役立ちますが、ifの場合に役立つことはほとんどありません。

単純なケースでは？：がより良い選択かもしれません。中程度の場合、多くの場合、スイッチの方が適しています（言語があれば）。複雑なケースでは、呼び出しテーブルの方が適している場合があります。

コードをリファクタリングするときに、パターンを明確にするために表形式に再配置したことが何度もありました。ほとんどの場合、問題を理解したら問題を解決するためのより良い方法があるという点で、私がそのようにしておくことはめったにありません。コーディング慣行またはレイアウト標準では禁止されている場合があり、その場合はコメントが役立ちます。

についていくつか質問がありました?:。はい、それは三項演算子です（または、私はそれを値と考えたいなら）。最初の赤面では、この例は？：で少し複雑です（そして？：を使いすぎると読みやすくなりませんが、痛いです）。解決。

if i==0: return 0
return i>0?sqrt(i):(1j*sqrt(-i))

テーブル形式に問題はありません。個人的な好みですが、私はこのような三項を使用します：

return i>0  ? sqrt(i)       :
       i==0 ? 0             :
              1j * sqrt(-i)

return毎回繰り返す必要はありません:)