スコープを示すために空白と{}を使用する言語の長所と短所は何ですか？[閉まっている]

空白を使用する方が良いのか、スコープを示すために括弧のようなトークンを使用する方が良いのかについて、矛盾があるようです。一貫性のないインデント問題に対する多くのpythonのソリューションを称賛しましたが、多くの意見が異なります：

トークンとして空白を含む言語は死ぬ必要があります。

同じ答えに後で投稿：

私は実際に試してみるまで、トークンとしての空白のようなものでした。おそらく、私の個人的な空白スペースのレイアウトが、python-landの誰もが使用しているものとほとんど一致するのを助けたでしょう。おそらく私は少しミニマリストなのかもしれませんが、とにかくインデントするつもりなら、なぜ{}に悩まされるのですか？

私はそれぞれの側にいくつかの明確な議論を見ることができます：

空白を使用：

• コードの一貫性のないインデントを減らすのに役立ちます
• 同じ目的を果たすために、目に見えるトークンを空白で置き換えることにより、画面をクリアします

トークンを使用：

• コードをさまざまなレベルにカットアンドペーストするのがはるかに簡単です（インデントを修正する必要はありません）
• より一貫性のある。一部のテキストエディタでは、空白が異なって表示されます。
• 現在より人気があります。

見逃した点はありますか？どっちがいい？どちらかと長い間働いた後の知恵の言葉はありますか？

PS。言語が各制御構造に同じトークンを使用しない場合、それは嫌いです。VBは、そのと本当に迷惑ですEnd Ifし、End While他のほとんどの言語は、単にすべてのために{}のを使用し、ステートメント。しかし、それは別の質問のトピックかもしれません...

多くのプログラマー（私自身も含む）は、すべての決定を「論理化」する傾向があると思います。それは問題ありませんが、すべての質問に論理的な答えがあるわけではありません。たとえば、シェフがchefoverflow（そのようなものが存在する場合）に質問を投稿して、アップルパイとチェリーパイの長所と短所を尋ねることを疑います。それはあなたがよりよく好きな質問です。

それを念頭に置いて、最も簡単な答えは、「ブレースが好きな人、空白が好きな人」と言って、そのままにしておくことだと思います。

完全なファンボーイのように聞こえるリスクがあるため、ホワイトスペースは「コード内の一貫性のないインデントを減らすのに役立つ」と主張する人は誰もVisual Studioを使用したことがないと思います。単一のコマンド（デフォルトのショートカットはCtrl + K、Dだと思います）で、すべてのインデントが瞬時に一貫します¹。さらに、コードを貼り付けると、インデントは何もすることなく瞬時に修正されます。また、新しいコードを書くとき、ifまたは何か他のブロックに何かをラップするときも同じことが当てはまります（}入力中に再フォーマットが行われます）。さらに、完了したステートメントの後にEnterキーを押すと、カーソルが次のステートメントの正しいインデントレベルに常に置かれます。ifまたは同様のことで、ステートメントがまだifそうでない場合に誤って考えることを非常に困難にします。

私がやろうとしているのは、Visual Studioが素晴らしいということではありません。私がしようとしている点は、プログラムの意味がそのフォーマットに依存しない場合にのみ、IDEがインデント修正（およびその他のフォーマットの問題）を自動化できることです。これにより、プログラマは実際のプログラミングタスクに集中することができます。Pythonのような構文は逆効果です。インデント自体がセマンティクスの一部を指定するため、Pythonコードのインデントを「修正」できるIDEを作成することはできません。

¹ _{（VSが再フォーマットすることを拒否する特殊なケース、つまり複数行にわたる配列リテラルがあることは知っていますが、それは重要なことです。）}

個人的には、コードが別のスコープ内にあることを気付かせるために、独自の行にトークンを持つことによって導入された空白行が必要であることがわかりました。

Pythonで人々が行くとき、私はそれを嫌います：

if something
    do something
    do somethingelse

    cleanup
else
    do the other thing

トークンランドでは、人々がコピーアンドペーストしてインデントをクリーンアップしないと嫌いです。

if something
{
I have been too lazy
      {
            to clean up
            }
what I pasted
}

または、トークンに別の行を使用しないでください。

if something {
    I find this confusing
}
else {
especially when combined with the previous 
do something
}

私は3つすべてを読むことができますが、私は期待して、私はそれらを解析するために努力を費やす必要はありやとそうではありませんジョエルは言うあなたはそれはあなたがイライラになり期待のようなものが作業をしないでくださいとき。

プロ：私の知る限り、Pythonの世界にはインデント/中括弧配置の聖戦はありません。開発者に代わってこの決定を行うことにより、おそらく多少の苦痛が軽減されます。

欠点：匿名関数は1行に制限されています。サウンド[OK]を、私は頻繁に自分自身がマルチラインアップ書き込みを見つけるlambda（主に飼料にするスキームで秒mapかapply、それは別に宣言する意味がありませんので、正確に一つの場所で）。

ホワイトスペース言語で見つかった問題は、複数ページの条件式にありました。ページ2の真ん中に行を追加し、すべての混乱の真ん中で1つのスペースで降りると、コードのロジックが大幅に変更される可能性があります。そして、たとえ誰かのコードが「正しい」としても、それを読み取ろうとすると、ひどい推測ゲームになります。この「else」はどの「if」ですか？見えない空白文字を数えるよりもはるかに簡単に中括弧を数えることができます。そして、このサイトの投稿機構は、それらを単一のスペースに破壊し続けます。

IMHO "{{{{{" is more reliable than "     ".

{}は冗長性を追加します。冗長性が多すぎると、少なすぎます。そして、手動で入力するのは悪いです、特に。使いにくい場合。

そのため、IDEが悪い/ない場合は、空白スタイルがわずかに改善される可能性があります。しかし、強力なIDEでは、ブレースが優れています。

私はそれが本当に対であるとは思わない。
Pythoneersは、まるでインデントに容易に違反するかのように、ブレースプログラマを批判します。
実際、Pythonとそのインデントスコープについて知る前であっても、常に100％一貫したインデントを使用していました。

事実は、ブレース言語はコンパイラに正しいインデントを課すことができ、両方の長所を持っているということです。見る？無対すべてで。

Pythoneersは、インデントが構文の一部である場合、ブレースは役に立たないと主張しますが、そうではありませんが、ブレースは読みやすさを向上させます。Pythonをプログラミングしてみましたが、私にとって非常に興味深い言語ですが、if-elif2つまたは3つ以上のインデントレベルのチェーンを試しましたか？彼らはもはやそれほどきれいに見えません。

PS：中括弧を書きましたが、より一般的な方法で、区切りトークンを意味します。開き括弧は冗長と見なすことができますが、言語は次のようになります（実際、このような言語は確かにありますが、私はそれらをよく知りません）。

if condition:
    statement
    other_statement()
end

PS2：2019、この回答の4年後。私はPythonを学び、セマンティックインデントに完全に慣れましたが、読むのは難しくありません。特に、インデントブロックの識別に役立つ垂直バーを描画する最新のIDEを使用します。