なぜ言語はブロックの明示的なマーカーよりもインデントを好むのですか？

Haskellを学んでいますが、自動インデントツールを探していました。私はあまり見ていませんでしたが、Haskellでは（Pythonのように）インデントがブロックを意味することを学びました。その結果、{}（中括弧）やbegin endキーワードなどの明示的なマーカーを使用する、Cファミリの他の言語ほど強力な自動書式設定ツールを作成することは不可能だと推測しています。

読みやすくするためにインデントを強制する言語は気にしませんが、インデントの強制と明示的なマーカーの両方の利点を理解できないため、自動化ツールはどのブロックに属するかを理解できます。

ブロックをマークするインデントの設定が、コードの見栄えを良くするためのものである場合、その利点はまだ理解できません。タブやスペースが異なるエディターや異なるフォント（モノスペースフォントは見栄えが良いなど）で異なって表されることを考えると、プログラマーがコードを適切に提示することを期待することは不可能です。現在のテキストエディタを考慮に入れることができるツールは、コードを正しくフォーマットするためにはるかに適切です。

言語設計者が明示的なブロックマーカーよりもインデントを選択するのはなぜですか？

グイド・フォン・ロッサム

books.google.com（エンファシス鉱山）で全文を見ることができるGuido Van Rossumのインタビューから：

グループ化のためのインデントの選択は、Pythonの新しい概念ではありませんでした。これはABCから継承しましたが、古い言語のoccamでも発生しました。ABCの作者がoccamからアイデアを得たのか、それとも独立して発明したのか、あるいは共通の祖先がいたのかはわかりません。もちろん、私は私が他の領域（例えば、ABCは、言語のキーワードとプロシージャ名のために、私はコピーしなかったアイデアを大文字を使用）、で行ったように、ABCのリードに従わないことを選んだかもしれないが、私は機能のように来ていたかなりビット、ABCを使用している間、Cの間での無意味な議論の共通の特定の種類を廃止するように見えたとしてについては、一度にユーザーの中括弧をどこに配置しますか。

Von RossumはABCから多大なインスピレーションを得ており、そのすべてをコピーする必要はありませんが、宗教戦争を避けるのに有益である可能性があるため、インデントの使用は維持されました。

また、読み取り可能なコードはグループ化を示すためにインデントを自発的に使用することもよく知っていました。インデントが中括弧を使用した構文グループ化と一致しないコードの微妙なバグに遭遇しました。したがって、バグに気づきませんでした。繰り返しますが、長いデバッグセッションは貴重な教訓を教えてくれました。

Rossumは、グループ化とインデントの不一致によるバグも目撃しましたが、コードの構造化のみにインデントを使用する方が、プログラミングエラー¹から安全になります。

ドナルドE.クヌース＆ピーターJ.ランディン

参照されたインタビューで、Guidoはインデントを使用するというDon Knuthのアイデアに言及しています。これは、再発見されたKnuth Indentation Quoteで詳しく説明されています。これは、構造化プログラミングとgotoステートメントを引用しています。Knuthは、Peter John LandinのThe next 700 programming languages（インデントについてのディスカッションセクションを参照）も参照しています。Landin は、開始/終了ブロックではなくインデントを使用した最初の言語のように見えるISWIMを設計しました。これらの論文は、プログラムを構造化するためにインデントを使用することの実現可能性に関するものであり、実際にそうすることを支持する議論ではありません。

_{1.これは実際には、発生するはずのプログラミングエラーをキャッチして回復するために、グループ化構造と自動フォーマットの両方を使用することを支持する議論だと思います。Pythonでインデントを台無しにした場合、コードをデバッグする人はどちらが正しいかを推測する必要があります。}

if (test(x)):
  foo(x)
  bar(x)

_{シャルbar常に呼び出されるかだけテストが成功した場合はどうなりますか？}

_{グループ化構造は、コードの自動インデント時に間違いを見つけるのに役立つ冗長性のレベルを追加します。Cでは、同等のコードを次のように自動インデントできます。}

if (test(x))
  foo(x);
bar(x);

_{barと同じレベルにすること を意図している場合foo、コード構造に基づいた自動インデントにより、fooとの周りに中括弧を追加することで修正できる問題があることがわかりますbar。}

_{でPythonの：インデントについての神話、Cからおそらく悪い例があります：}

/*  Warning:  bogus C code!  */

if (some condition)
        if (another condition)
                do_something(fancy);
else
        this_sucks(badluck);

_{これは上記と同じです。Emacsでは、ブロック/関数全体を強調表示し、Tabキーを押すと、すべてのコードが再インデントされます。人間のインデントとコード構造の不一致は、何かがずれていることを示しています（それと前のコメント！）。}

_{その上、Cでインデントがオフになっている中間コードは、単にmasterブランチを通過しません。すべてのスタイルチェックが行われると、GCC / Jenkinsが悲鳴を上げます。私は最近、Pythonで上記で説明したものと同様の問題を抱えていました。Cで閉じ括弧を超えるコードがある場合もありますが、Tabキーを押すとコードが「間違って」インデントします。これはバグを確認するもう1つの機会です。}

これは非常に主観的であり、多くの火炎戦争の原因です。しかしながら：

ブロックとインデントを区切る記号があると、同じ情報を2つの異なる方法で表現するため、DRY原則に違反します。自動インデントツールの存在は、このDRY違反の症状です。インデントを自動的に生成できることは、それが冗長な情報であることを示し、インデントとシンボルが同期しなくなり、誤解を招くコードにつながる可能性があることを意味します。

Python Design and History FAQはこれを非常に明確に述べています：

Pythonがステートメントのグループ化にインデントを使用するのはなぜですか？

Guido van Rossumは、グループ化にインデントを使用することは非常にエレガントであり、平均的なPythonプログラムの明快さに大きく寄与すると考えています。ほとんどの人はしばらくしてこの機能を愛するようになります。

開始/終了ブラケットがないため、パーサーと人間のリーダーが認識するグループ化の間に不一致はありません。

Python用の自動インデントツールを作成できないのは事実ですが、これは良いことです。つまり、調整に自動化ツールが必要な構文に冗長性がないことを意味します。

タブとスペースはPythonの正当な懸念事項であり、同じコードベースでタブとスペース（インデント用）を混在させないことをお勧めします。

Pythonは、（現在は廃止された）先行言語ABCから重要なインデントを継承しました。ABCは、ユーザビリティテストを使用して設計を指示した数少ないプログラミング言語の1つです。したがって、構文に関する議論は通常主観的な意見と個人的な好みに帰着しますが、重要なインデントの選択は実際にはより健全な基盤を持っています。

言語設計者は、セミコロンとブレースがコードの読み取り時にノイズを追加し、生産性を損なうと信じている（または少なくとも潜在的なユーザーが信じていると思う）ため、構文的に重要な空白を選択します。別の一般的な理由は、悪い/一貫性のないコーディングスタイルが読みやすさを損なうことです。共通のインデントスキームを強制することにより、言語の全体的な読みやすさが向上します。IDEの自動フォーマットがより一般的である今では、その後者の理由はそれほど重要ではありませんが、まだ適用できます。