Stack OverflowとPEP 8で、Pythonプログラムのインデントにはスペースのみを使用することをお勧めします。一貫したインデントの必要性を理解でき、その痛みを感じました。
スペースが優先される根本的な理由はありますか?タブの方がはるかに扱いやすいと思いました。
Stack OverflowとPEP 8で、Pythonプログラムのインデントにはスペースのみを使用することをお勧めします。一貫したインデントの必要性を理解でき、その痛みを感じました。
スペースが優先される根本的な理由はありますか?タブの方がはるかに扱いやすいと思いました。
回答:
答えはPEPのすぐそこにありました[ed:この一節は2013年に編集されました]。私は引用します:
最も人気のある Pythonのインデントの方法は、スペースのみです。
他に必要な根本的な理由は何ですか?
簡単に言えば、最初の段落で述べたPEPの範囲も考慮してください。
このドキュメントは、メインのPythonディストリビューションの標準ライブラリを構成するPythonコードのコーディング規約を提供します。
その意図は、公式のPythonディストリビューションに含まれるすべてのコードを一貫した形式にすることです(これが普遍的にGood Thing™であることに同意できることを願っています)。
個々のプログラマーのスペースとタブの間の決定は、a)本当に好みの問題であり、b)技術的手段(エディター、変換スクリプトなど)によって簡単に処理されるため、すべての議論を終了する明確な方法があります。 。
選択するのはグイドでした。彼は理由を述べる必要はなかったが、それでも経験的なデータを参照することによってそうした。
他のすべての目的のために、このPEPを推奨事項として使用するか、それを無視することができます(選択、チーム、またはチームリーダー)。
しかし、私があなたに一つのアドバイスを与えるかもしれない場合:混ぜないでください;-) [ed:タブとスペースの混在はもはやオプションではありません。]
まあ、誰もが空間に強く偏っているようです。タブのみを使用しています。理由はよくわかります。
タブは実際にはスペースの後に生まれたクールな発明です。何百万回もスペースを押したり、スペースを生成する偽のタブを使用したりせずにインデントすることができます。
誰もがタブの使用を差別しているのはなぜかわかりません。これは、高齢者が若い人を差別して新しいより効率的なテクノロジーを選択し、パルスダイヤリングがこれらの派手な新しいものだけでなくすべての電話で機能することを訴えるのとよく似ています。「トーンダイヤリングはすべての電話で機能するわけではありません。そのため、それは間違っています。」
エディターはタブを適切に処理できませんか?さて、最新のエディターを入手してください。今こそ21世紀の時代であり、編集者がハイテクで複雑なソフトウェアの一部であった時代はもう過ぎ去っています。現在、膨大な数のエディターから選択することができ、それらすべてがタブをサポートしています。また、タブをいくらにするかを定義することもできます。スペースではできません。タブが表示されませんか?議論についてそれは何ですか?まあ、スペースも見えない!
より優れたエディターを手に入れるために私が大胆に提案してもいいですか?10年ほど前にリリースされたこれらのハイテク製品の1つで、目に見えない文字が表示されますか?(皮肉オフ)
スペースを使用すると、削除とフォーマットの作業が大幅に増加します。これが(そしてこれを知って私に同意する他のすべての人々が)Pythonにタブを使用する理由です。
タブとスペースを混在させることは、禁止事項ではありません。それはめちゃくちゃで、うまくいかない。
私は個人的にタブの上のスペースに同意しません。私にとって、タブはドキュメントレイアウトの文字/メカニズムであり、スペースはコードの場合のコマンド間のコンテンツまたは区切りのためです。
タブは本当に問題ではなく、人々とタブとスペースをどのように混在させたいかが問題であるというジムのコメントに同意する必要があります。
とはいえ、私は慣習上スペースを使わざるをえませんでした。私は個人の好みよりも一貫性を重視しています。
スペースの理由は、タブがオプションであるためです。スペースは、句読点の実際の最も一般的な分母です。
すべてのまともなテキストエディタには「タブをスペースに置き換える」機能があり、多くの人がこれを使用しています。しかしいつもではない。
一部のテキストエディターは一連のスペースをタブに置き換える場合がありますが、これは非常にまれです。
ボトムライン。スペースがあっても間違いはありません。タブに問題があるかもしれません。そのため、タブを使用しないで、ミスのリスクを減らしてください。
タブの問題は、タブが見えず、人々がタブの幅に同意できないことです。タブとスペースを混在させ、タブストップをPython以外の場所に設定すると(8つのスペースごとにタブストップを使用)、Pythonとは異なるレイアウトでコードが表示されます。また、レイアウトによってブロックが決まるため、さまざまなロジックが表示されます。微妙なバグにつながります。
または悪化し、タブとスペースを混合- -あなたがPEP 8を挑むとタブを使う、という場合は、少なくとも常に作る「-tt」引数、とのpythonを実行矛盾インデント(時にはタブ、同じインデントのために、時にはスペースをレベル)エラー。また、可能であれば、タブを異なる方法で表示するようにエディターを設定してください。しかし、実際には、タブ、ピリオドを使用しないことが最善のアプローチです。
インデントに関する主な問題は、タブとスペースを混在させると発生します。明らかにこれはあなたがどちらを選択すべきかを教えてくれませんが、コインを投げてそれを選んだとしても、それを推薦するのは良い理由です。
ただし、IMHOタブよりもスペースを優先するいくつかのマイナーな理由があります。
さまざまなツール。コードがプログラマーのエディターの外に表示されることがあります。例えば。ニュースグループまたはフォーラムに投稿されました。ここではスペースは一般にタブよりも優れています-スペースが壊れるところはどこでも、タブも同様ですが、その逆ではありません。
プログラマーはソースの見方を変えます。これは非常に主観的です。タブの主な利点か、どちらの側にあるかによってタブを回避する理由のどちらかです。プラス面として、開発者は好みのインデントでソースを表示できるため、2スペースインデントを好む開発者は、同じソースで8スペースの開発者と一緒に作業しても、好きなように表示できます。欠点は、これには反響があることです。8スペースのようにネストが深すぎるという非常に目に見えるフィードバックを提供するため、8スペースが好きな人もいます。すべての開発者に同じ方法でコードを見てもらうと、行の長さなどの一貫性が向上します。
行のインデントを続けます。行をインデントして、前の行から移動したことを示すことが必要な場合があります。例えば。
def foo():
x = some_function_with_lots_of_args(foo, bar, baz,
xyzzy, blah)
タブを使用している場合、スペースとタブを混在させずにエディターで異なるタブストップを使用しているユーザーがこれを調整する方法はありません。これにより、上記のメリットが効果的に失われます。
もちろん、これは非常に宗教的な問題であり、プログラミングはこの問題に悩まされています。最も重要な問題は、1つを選択する必要があることです。時々私は重要なインデントの最大の利点は、少なくともブレース配置フレームウォームを免れていることだと思います。
タブを使用すると、PEP 8の別の側面が混乱することに注意してください。
すべての行を最大79文字に制限します。
仮に、タブ幅2を使用し、タブ幅8を使用するとします。最長の行が79文字になるようにすべてのコードを記述してから、ファイルの作業を開始します。(PEPの状態によると)次の理由により、コードが読みにくくなりました。
ほとんどのツールのデフォルトのラッピングは、コードの視覚的な構造を混乱させます
私たち全員が4つのスペースを使用する場合、それは常に同じです。エディターが80文字幅をサポートできる人なら誰でも、コードを快適に読み取ることができます。注:80文字の制限はそれ自体が聖戦であるため、ここでは開始しません。
しゃべらないエディタには、タブのように(挿入と削除の両方で)スペースを使用するオプションがあるはずです。そのため、これは実際には有効な引数ではありません。
質問に対する答えは次のとおりです。PEP-8は推奨事項を作成することを望んでおり、スペースの方が人気があるため、タブよりもスペースを強く推奨することを決定しました。
PEP-8に関する注意
PEP-8は「インデントレベルごとに4つのスペースを使用する」と言います。
これが標準の推奨事項であることは明らかです。
「めちゃくちゃにしたくない本当に古いコードの場合は、8スペースのタブを引き続き使用できます。」
タブを使用できる状況がいくつかあることは明らかです。
「タブとスペースを混在させないでください。」
これは明らかに混合の禁止です-私たちは皆これに同意すると思います。Pythonはこれを検出でき、多くの場合は窒息します。-tt引数を使用すると、これは明示的なエラーになります。
'Pythonをインデントする最も一般的な方法はスペースのみです。2番目に人気のある方法はタブのみです。
これは明らかに両方が使用されていることを示しています。非常に明確にするために、スペースとタブを同じファイルに混在させないでください。
「新しいプロジェクトでは、タブよりもスペースのみを強くお勧めします。」
これは明確な推奨事項であり、強力な推奨事項ですが、タブの禁止ではありません。
PEP-8で自分の質問に対する良い答えが見つかりません。私はこれまで他の言語で使用してきたタブを使用しています。Pythonは、タブを排他的に使用するソースを受け入れます。それで十分です。
スペースでの作業に挑戦したいと思いました。私のエディターでは、スペースのみを使用するようにファイルタイプを構成したので、Tabキーを押すと4つのスペースが挿入されます。タブを何度も押すと、スペースを削除する必要があります! ああ! 削除はタブの4倍!私の編集者は、インデントに4つのスペースを使用していることを認識できません(ただし、ANエディターがこれを実行できる場合があります)。明らかに、一度に1つずつスペースを削除するように要求しています。
Pythonは、インデントを読み取るときにタブをnスペースと見なすように指示できませんか?インデントごとに4つのスペースとタブごとに4つのスペースについて合意し、Pythonでこれを受け入れることができれば、問題はありません。
問題の双方に有利な解決策を見つける必要があります。
[人々が]コードを読んでいて、新しいコードの作成が終わったら、新しいスコープ(またはsexprなど)が開いたときにコードがインデントする傾向がある画面列の数を気にします...
...私の意見では、技術的な問題を解決する最善の方法は、ASCII#9 TAB文字がディスクファイルに表示されないようにすることです:行をディスクに書き込む前に、エディターでTABを適切な数のスペースに拡張するようにプログラムします。 ..
...これは、文字列定数や文字定数など、実際に重要な場所でタブを使用しないことを前提としていますが、絶対に使用しません。タブであることが重要な場合は、代わりに常に「\ t」を使用します。
Pythonはプログラム構造を認識するためにインデントに依存しているため、IDを識別する明確な方法が必要です。これが、スペースまたはタブを選択する理由です。
ただし、pythonにも物事を行う方法が1つしかないという強い哲学があるため、インデントを行う1つの方法に関する公式の推奨事項があります。
スペースとタブの両方は、エディターがインデントとして処理するために独特の課題を提起します。タブ自体の処理は、エディター間またはユーザー設定間で統一されていません。スペースは構成可能ではないため、結果がどこでも同じになることを保証するため、より論理的な選択が可能になります。
タブよりもスペースの方が優れていると言える最も重要な利点は、多くのプログラマーやプロジェクトがソースコードに設定された数の列を使用し、タブストップを2スペースに設定して変更をコミットし、プロジェクトが4スペースをタブストップの長い行は、他の人のエディタウィンドウには長すぎます。タブの方が扱いやすいことに同意しますが、スペースはコラボレーションの方が簡単だと思います。これは、Pythonのような大規模なオープンソースプロジェクトでは重要です。
あなたはあなたのケーキを持って、それを食べることができます。自動的にタブをスペースに展開するようにエディターを設定します。
(それは:set expandtab
Vimにあります。)
私の推測では、ほとんどのLinuxテキストエディタは、デフォルトをデフォルトで途方もなく大きく見せています。タブの上にスペースを使用する他の理由はありません。
既に指定されている他のすべての理由(一貫性、スペースとタブを決して混在させないなど)に加えて、4つのスペースの規則に注意する理由がさらにいくつかあると思います。これらはPython(およびおそらくインデントが意味を持つ他の言語)にのみ適用されます。個々の設定によっては、他の言語ではタブの方が優れている場合があります。
エディターにタブが表示されない場合(構成によってはかなりの数が発生します)、別の作成者がコードで4つのスペースを使用していると想定する場合があります。b/ cほとんどすべてのPythonコードが公開されています。同じエディタのタブ幅が4の場合、厄介なことが起こる可能性があります。少なくとも、貧しい人は、慣習に固執することで非常に簡単に回避できるインデントの問題で時間を失うことになります。だから私にとって、一番の理由は一貫性のあるバグを避けることです。
タブとスペースのどちらが良いかという問題を再構成する場合、タブの利点がどれであるかを尋ねる必要があります。タブを称賛する投稿はたくさんありますが、タブに対する説得力のある議論はほとんどありません。emacs、vi(m)、kateなどの優れたエディターは、コードのセマンティクスに応じて適切なインデントを行います。同じエディターは、バックスペースなどでインデントを解除するように簡単に構成できます。
一部の人々は、コードの外観/レイアウトを決定する自由に関して、非常に強い好みを持っています。他の人はこの自由についての一貫性を評価します。Pythonは、ブロックなどにインデントが使用されることを指示することにより、この自由度を大幅に削減します。これは、バグまたは機能と見なされる場合がありますが、Pythonを選択することである程度発生します。個人的には、私はこの一貫性が好きです。新しいプロジェクトでコーディングを開始するとき、少なくともレイアウトは私が慣れているものに近いので、かなり読みやすいです。ほとんどいつも。
インデントにスペースを使用すると、コードを理解しやすくなる「レイアウトトリック」が可能になります。これらのいくつかの例がPEP8にリストされています。例えば。
foo = long_function_name(var_one, var_two,
var_three, var_four)
# the same for lists
a_long_list = [1,
2,
# ...
79]
# or dictionaries
a_dict = {"a_key": "a_value",
"another_key": "another_value"}
もちろん、上記は次のようにうまく書くこともできます
foo = long_function_name(
var_one, var_two,
var_three, var_four)
# the same for lists
a_long_list = [
1,
2,
# ...
79]
# or dictionaries
a_dict = {
"a_key": "a_value",
"another_key": "another_value"}
ただし、後者はより多くのコード行を必要とし、より少ない行がより良いと主張されることがあります(b / c 1つの画面でより多くを取得します)。しかし、アラインメントが好きな場合、スペース(優れたエディターで支援されることが望ましい)は、ある意味で、タブよりもPythonの自由度を高めます。[まあ、一部のエディターではタブと同じようにできる;)-しかしスペースがあれば、すべてのエディターがそうする...]
他の皆がするのと同じ議論に戻る-PEP 8はスペースを指示します(大丈夫、強くお勧めします)。もちろん、タブのみを使用するプロジェクトの場合は、選択肢がほとんどありません。しかし、PEP 8規約の確立により、ほとんどすべてのPythonプログラマーがこのスタイルに慣れています。これにより、ほとんどのプログラマーが受け入れているスタイルについてのコンセンサスを見つけるのが非常に簡単になります。そうしないと、スタイルについて個人に同意させるのが非常に難しい場合があります。
スタイルの強制に役立つツールは、通常、余分な労力なしでPEP 8を認識します。それは大きな理由ではありませんが、すぐに機能するのは素晴らしいことです。
タブの一般的な問題は、タブが異なる環境で異なる方法で表現できることです。
特定のエディターでは、タブが8スペースまたは2
である場合があります。エディターによっては、これを制御できる場合とできない場合があります。
タブに関するもう1つの問題は、タブが印刷出力でどのように表されるかです。ほとんどのプリンターはタブを8スペースとして解釈すると思います。
スペースがあれば間違いありません。すべてが作者の意図したとおりに並びます。
コメントでのジムとトーマス・ウータースの議論について。
問題は...タブとスペースの両方の幅が変わる可能性があるため-プログラマーがどちらの幅にも同意できないため-タブのせいになっているのはなぜですか?
私はジムに同意します-タブ自体は悪ではありません。しかし問題がある...
スペースを使用して、「MY OWN CODE」を制御できます と、世界中のすべてのエディターでがます。4つのスペースを使用する場合、どのエディターでコードを開いても、左マージンからの距離は同じになります。タブの場合、私はエディターのタブ幅設定に翻弄されています-自分のコードについても同様です。そして、私はそれが好きではありません。
したがって、スペースでも一貫性を保証できないことは事実ですが、少なくともスペースによって、どこでもOWNコードの外観をより詳細に制御できます。タブでは不可能です。
プログラマーがコードを書くときの一貫性ではなく、そのコードを表示するエディターの一貫性が原因です。スペースを使用することで、実現が容易になります。