Stack Overflow とPEP 8で、Python プログラムのインデントにのみスペースを使用することが推奨されていることがわかりました。一貫したインデントの必要性を理解でき、その痛みを感じました。
スペースが優先される根本的な理由はありますか? タブの方がはるかに使いやすいと思っていたでしょう。
Stack Overflow とPEP 8で、Python プログラムのインデントにのみスペースを使用することが推奨されていることがわかりました。一貫したインデントの必要性を理解でき、その痛みを感じました。
スペースが優先される根本的な理由はありますか? タブの方がはるかに使いやすいと思っていたでしょう。
そうですね、みんな宇宙に偏っているようですね。タブのみを使用します。私はその理由をよく知っています。
タブは実際には、スペースに続くクールな発明です。これにより、何百万回もスペースを押したり、偽のタブ (スペースを生成する) を使用したりせずにインデントできます。
誰もがタブの使用を差別している理由が本当にわかりません。それは、高齢者がより効率的な新しい技術を選択した若者を差別し、パルスダイヤルがこれらの派手な新しい電話だけでなく、すべての電話で機能すると不平を言っているのと非常によく似ています。「トーンダイヤルはすべての電話で機能するとは限りません。それが間違っている理由です」.
あなたのエディタはタブを適切に処理できませんか? さて、最新のエディターを入手してください。今は 21 世紀で、エディターがハイテクで複雑なソフトウェアだった時代はとうの昔に過ぎ去っています。現在、選択できるエディタは無数にあり、それらはすべてタブを適切にサポートしています。また、タブの大きさを定義することもできますが、これはスペースではできません。タブが表示されませんか? それは議論のために何ですか?まあ、あなたもスペースを見ることはできません!
より良い編集者を見つけることを大胆に提案してもよろしいですか? すでに10年ほど前にリリースされたこれらのハイテクのものの1つは、目に見えない文字を表示しますか? (皮肉オフ)
スペースを使用すると、より多くの削除およびフォーマット作業が発生します。それが (そしてこれを知っていて私に同意する他のすべての人々) が Python のタブを使用する理由です。
タブとスペースを混在させることは禁止されており、それについての議論はありません。それは混乱であり、決して機能しません。
答えは PEP [ed: この節は2013 年に編集されました] ですぐに与えられました。私は引用します:
Python をインデントする最も一般的な方法は、スペースのみを使用する方法です。
他にどのような根本的な理由が必要ですか?
率直に言うと、最初の段落で述べたように、PEP の範囲も考慮してください。
このドキュメントは、主要な Python ディストリビューションの標準ライブラリを構成する Python コードのコーディング規則を示しています。
意図は、公式の python ディストリビューションに含まれるすべてのコードを一貫してフォーマットすることです (これが普遍的に Good Thing™ であることに同意できることを願っています)。
個々のプログラマにとってスペースとタブの間の決定は、a) 本当に好みの問題であり、b) 技術的な手段 (エディタ、変換スクリプトなど) によって簡単に処理できるため、すべての議論を終了する明確な方法があります: 1 つを選択してください。 .
選んだのはグイド。彼は理由を述べる必要さえありませんでしたが、それでも彼は経験的なデータを参照して言いました。
他のすべての目的については、この PEP を推奨事項として受け入れるか、無視することができます (あなたの選択、チームの選択、またはチーム リーダーの選択)。
しかし、私があなたに1つのアドバイスを与えることができるなら:それらを混ぜないでください;-) [編集:タブとスペースを混ぜることはもはやオプションではありません.]
タブの問題は、タブが見えないことであり、人々はタブの幅に同意することはできません。タブとスペースを混在させ、Python以外の場所にタブストップを設定すると(8スペースごとにタブストップを使用します)、Pythonとは異なるレイアウトでコードが表示されます。また、レイアウトによってブロックが決まるため、さまざまなロジックが表示されます。それは微妙なバグにつながります。
PEP 8に逆らい、タブを使用することを主張する場合、またはさらに悪いことに、タブとスペースを混在させる場合は、少なくとも常に'-tt'引数を指定してPythonを実行します。これにより、インデントが一貫しなくなります(タブの場合もあれば、同じインデントのスペースの場合もあります)。レベル)エラー。また、可能であれば、タブを別の方法で表示するようにエディターを設定してください。しかし実際には、最善のアプローチはタブ、ピリオドを使用しないことです。
スペースの理由は、タブがオプションであるためです。スペースは、句読点の実際の最小公倍数です。
すべての適切なテキスト エディターには「タブをスペースに置き換える」機能があり、多くの人がこれを使用しています。しかしいつもではない。
一部のテキスト エディターでは一連のスペースがタブに置き換えられる場合がありますが、これは非常にまれです。
ボトムライン。スペースを間違えることはありません。タブを間違える可能性があります。したがって、タブを使用しないで、間違いのリスクを減らしてください。
タブとスペースを混在させると、インデントに関する主な問題が発生します。明らかに、これはどれを選択すべきかを示しているわけではありませんが、コインを投げて選択したとしても、1 つを推奨する十分な理由になります。
ただし、私見では、タブよりもスペースを優先するいくつかの小さな理由があります。
さまざまなツール。コードがプログラマーのエディターの外に表示されることがあります。例えば。ニュースグループまたはフォーラムに投稿されました。ここでは通常、スペースはタブよりもうまく機能します - スペースが台無しになる場所ならどこでも、タブも同様に機能しますが、その逆はありません。
プログラマーはソースを別様に見ています。これは非常に主観的なものです。タブの主な利点であるか、どちらの側にいるかに応じてタブを避ける理由のいずれかです。プラス面として、開発者は好みのインデントでソースを表示できるため、2 スペースのインデントを好む開発者は、同じソースで 8 スペースの開発者と協力して、好きなように表示できます。マイナス面は、これには影響があるということです。ネストが深すぎるという非常に目に見えるフィードバックが得られるため、8 スペースを好む人もいます。2 インデンターによってチェックインされたコードが常にエディターでラップされているのが見える場合があります。すべての開発者に同じようにコードを見てもらうことで、行の長さやその他の問題についての一貫性が高まります。
行インデントの続き。前の行から引き継がれていることを示すために行をインデントしたい場合があります。例えば。
def foo():
x = some_function_with_lots_of_args(foo, bar, baz,
xyzzy, blah)
タブを使用している場合、スペースとタブを混在させずにエディターで異なるタブストップを使用している人々のためにこれを揃える方法はありません。これにより、上記の利点が効果的に失われます。
明らかに、これは非常に宗教的な問題であり、プログラミングが悩まされています。最も重要な問題は、1 つを選択する必要があるということです。それがあなたの好みでなくても。大きなインデントの最大の利点は、少なくともブレース配置のフレームワークを回避できることだと思うことがあります。
また、この問題に関する Jamie Zawinski の記事も読む価値があります。
タブを使用すると、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 は、タブを排他的に使用するソースを受け入れます。私にはそれで十分です。
スペースを使って仕事をしてみようと思いました。私のエディターでは、スペースのみを使用するようにファイルの種類を構成したため、タブを押すと 4 つのスペースが挿入されます。タブを何度も押すと、スペースを削除する必要があります。 ああ! タブの 4 倍の削除数! 私の編集者は、私がインデントに 4 つのスペースを使用していることを認識できず (ただし、AN の編集者はこれを実行できる可能性があります)、明らかにスペースを 1 つずつ削除するように主張します。
インデントを読むときに、タブを n 個のスペースと見なすように Python に指示できませんでしたか? インデントごとに 4 つのスペース、タブごとに 4 つのスペースに同意し、Python がこれを受け入れられるようにすることができれば、問題はありません。
私たちは、問題に対するウィンウィンの解決策を見つけなければなりません。
コードでは常にタブを使用してきました。そうは言っても、最近、スペースを使用する理由がわかりました。Nokia N900 インターネット タブレットで開発していたとき、タブ キーのないキーボードを使用していました。これにより、タブをコピーして貼り付けるか、コードをスペースで書き直す必要がありました。他の電話でも同じ問題に遭遇しました。確かに、これは Python の標準的な使い方ではありませんが、覚えておくべきことがあります。
Python はプログラム構造を認識するためにインデントに依存しているため、ID を識別する明確な方法が必要です。これが、スペースまたはタブのいずれかを選択する理由です。
ただし、python には、物事を行う方法は 1 つしかないという強い哲学もあるため、インデントを行う方法については公式に推奨する必要があります。
スペースとタブはどちらも、エディターがインデントとして処理するための固有の課題をもたらします。タブ自体の処理は、エディターやユーザー設定で統一されていません。スペースは構成可能ではないため、結果がどこでも同じに見えることが保証されるため、より論理的な選択肢になります。
[人々が] コードを読んでいるとき、そして新しいコードを書き終わったとき、彼らは、新しいスコープ (または sexpr など) が開いたときにコードがインデントする傾向がある画面列の数を気にします...
...私の意見では、技術的な問題を解決する最善の方法は、ディスク ファイルに ASCII #9 TAB 文字が表示されないようにすることです。行をディスクに書き込む前に、TAB を適切な数のスペースに展開するようにエディタをプログラムしてください。 ..
...これは、文字列や文字定数など、実際に重要な場所でタブを使用しないことを前提としていますが、私は決して使用しません。タブであることが重要な場合は、代わりに常に '\t' を使用します。
あなたはあなたのケーキを持って食べることができます。タブをスペースに自動的に展開するようにエディターを設定します。
(それは:set expandtab
Vimにあります。)
タブよりもスペースについて私が言える最も重要な利点は、多くのプログラマーとプロジェクトがソース コードに設定された数の列を使用し、誰かがタブストップを 2 つのスペースに設定して変更をコミットし、プロジェクトが 4 つのスペースを使用する場合です。タブストップ長い行は、他の人のエディター ウィンドウには長すぎます。タブの方が作業しやすいという意見には同意しますが、スペースの方がコラボレーションしやすいと思います。これは、Python のような大規模なオープン ソース プロジェクトでは重要です。
タブの一般的な問題は、タブが異なる環境で異なる方法で表現される可能性があることです。
特定のエディターでは、タブは8スペースまたは2スペースである場合があります。
一部のエディターでは、これを制御できますが、他のエディターでは制御できません。
タブに関するもう1つの問題は、タブが印刷出力でどのように表されるかです。ほとんどのプリンターはタブを8つのスペースとして解釈すると思います。
スペースがあれば、間違いありません。著者が意図したとおりにすべてが整列します。
すでに名前が挙げられている他のすべての理由 (一貫性、スペースとタブを混在させないなど) に加えて、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 を認識します。それは大した理由ではありませんが、箱から出してすぐに動作するのは素晴らしいことです。
コメントでのジムとトーマス・ウーターズの議論について。
問題は...タブとスペースの幅は両方とも異なる可能性があるため、プログラマーはどちらの幅にも同意できないため、タブが責任を負うのはなぜですか。
私はそれについてジムに同意します-タブはそれ自体悪ではありません。しかし問題がある...
スペースを使用する と、世界中のすべてのエディターで「MY OWN CODE」がどのように表示されるかを制御できます。4 つのスペースを使用すると、どのエディターでコードを開いても、左マージンから同じ距離になります。タブを使用すると、エディターのタブ幅設定に翻弄されます-自分のコードであっても。そして、私はそれが好きではありません。
したがって、スペースでさえ一貫性を保証できないことは事実ですが、少なくともどこでも OWN コードの外観をより詳細に制御できますが、これはタブでは不可能なことです。
コードを書くプログラマーの一貫性ではなく、そのコードを表示するエディターの一貫性が、スペースが実現 (および押し付け) を容易にするのだと思います。