タブとスペースを混在させることの欠点は何ですか？
インデントにタブを使用する利点は、使いやすいタブ幅を使用するようにエディターを構成できることです。これに対する唯一の議論は、人々がエディターの設定に基づいてコードを別様に見せたくないということです。ただし、コードは最終的には後で読みやすくなるように作成されているため、リーダーが幅を適切な値に設定できるようにする方がはるかに有益です。
一方、タブの幅は環境によって異なるため、タブを使用して複数行のステートメントなどをフォーマットすると、位置合わせの問題が発生します。
この例は次のとおりです。
print(name + " is now " + age +
"years old!")
ただし、この場合、2行目の前のスペースの目的は、ブロックをインデントするために使用される目的とは非常に異なります。ここでの目的は、2行目をprint(文字、ここでの最善の解決策は、スペースを使用することです。スペースが上の行の各文字と同じ幅であることが保証されているためです。
要約すると、何が悪いのか
...インデントにタブを使用して、誰でも自分の好みの幅を設定できる
...スペースを使用して、幅doesが重要な場合に複数行のコードを整列します
これらの質問のほとんどは、通常、単なるタブとスペースの両方であるため、ここでは、それぞれを個別のユースケースに使用することの利点/欠点について、さらに洞察を得たいと思います。
1。最初の欠点は、すぐに混乱することです
最も使用されているVisual Studio拡張機能の1つは、生産性向上ツールです。この拡張機能には、ファイルでタブとスペースの両方が使用されている場合に警告するオプションがあり、タブをスペースで置き換えるか、スペースをタブで置き換えるかを提案します。
これは、ファイルを開いたときに、スペースやタブを使用している場合は視覚的な手掛かりがないためです。ある開発者はタブのみを使用し、別の開発者はインデントを含めてスペースのみを使用し、別の開発者はあなたが提案した方法で両方を使用します。
これらの3人の開発者が一緒に作業する場合、すべてが異なるスタイルを使用しているため、4人目の開発者は、タブまたはスペースを使用する必要があるかどうか、いつ使用するのかまったくわかりません。
2。2番目の欠点は、今日のIDEがそのために行われていないことです。
あなたが信じているように、実際の問題を解決する代わりに、それはそれを増加させるだけです。
あなたの慣習を使用して、インデントされた/整列されたコードを想像してください：
→ Some code here(firstArgument,
→ ···············secondOne,
→ ···············andTheLast);
実際、実際には、次のようなことが起こります。
→ Some code here(firstArgument,
→ → → → ···secondOne,
→ → → → ···andTheLast);
正直なところ、スペースキーと同様に繰り返しテーピングしている自分はほとんど見えないため、タブの配置を停止してスペースの使用を開始する瞬間を正確に判断する（つまり、1つのタブの次にスペース）。
いくつかの変更後、同じコードがすぐに次のようになる可能性があります。
→ Some code here(firstArgument,
→ → → → ···secondOne,
→ → → ·······modified);
ここで、誰かがIDEでファイルを開く場合、タブが4つではなく2つのスペースに等しい場合、それが表示されます。
→ Some code here(firstArgument,
→ → → → ···secondOne,
→ → → ·······modified);
言い換えると：
Some code here(firstArgument,
secondOne,
modified);
。最後に、問題はそもそも存在しません。
最初の引数はメソッド自体と同じ行にある必要があると想定しています。しかし、最も簡単な方法は、引数が長すぎる場合にすべての引数を新しい行に単に置くことです。上記のコードは次のように書くだけです：
→ Some code here(
→ → firstArgument,
→ → secondOne,
→ → andTheLast);
見る？それはすべて揃っていて、タブが測定するスペースの大きさに関係なくです。
結論：
フォーマットはIDEのタスクである必要があります。 開発者はすでにタブのサイズ、スペースの量に注意するのに十分な作業を行っていますIDE挿入などコードは正しくフォーマットされ、正しく表示されるはずです開発者にそれについて考えることを強制することなく、他の構成。
タブがインデントに使用され、スペースが位置合わせに使用される規則を導入することにより、IDEから開発者にタブ/スペースに関する注意を払う作業を軽減できます。それは間違っている。
原則として、ブロックのインデントにタブを使用し、さらに位置合わせするためにスペースを使用しても問題はありません。
ただし、いくつかの実用的な問題があります。
- インデントにタブを使用することがわかっている場合、役立つようにしてXスペースをタブに置き換えるエディターがあると思います。
- チームの1人の人だけが不適切に設定されたエディターを使用して、すべてが大混乱に陥る
これらの理由により、インデントにタブを使用し、レイアウトにスペースを使用するコードベースで一貫したレイアウトを構築することは実際にはほぼ不可能です。そのため、ほとんどのチームは簡単な方法で、スペースのみを使用する必要があります。ほとんどのプログラミングエディターは、<Tab>キーを押した場合にいくつかのスペースを挿入するように構成できます。そのため、プログラマーは引き続きそのキーを使用して必要なインデントを取得できます。
何が悪いの
...インデントにタブを使用して、誰でも自分の好みの幅を設定できる...幅が重要な場合に複数行のコードを配置するためにスペースを使用する
何も問題はありません。実際、これは「タブ対スペース」戦争の最良の解決策です。すでにお気づきのように、一貫性を維持しながら、（タブ幅設定によって）必要な人のためにブロックのインデントの深さを変えることができるためです。ブロック内でのフォーマット（次第に義務付けられる、または少なくともPython用PEP8などの言語スタイルガイドで強く推奨される）。
ここで正解は1つだけです。つまり、プログラマーであれば、適切なIDEまたはプログラマーがコードを編集するために使用するエディターを使用する必要があります。メモ帳を使用している人またはNanoと手動によるインデントはEdgeケースです。Eclipse、Emacs、Vim、XCodeはすべて、「ブロックのタブ、複数行ステートメントの配置用のスペース」メソッドを使用してコードを自動的にインデントするように設定できます。これは、 Pythonの場合、PEP8は「すべてのスペースとタブなし」が推奨されると述べています（したがって、そこでも議論する必要はありません）。
私はEmacsを支持しますが、使い慣れたツールを既に持っている他の開発者にそれを強制することはしませんそのツールが機能する限り。タブとスペースを「討論」して編集者の聖戦に変える人々は、要点を見逃しています。手でインデントしている場合は、間違っています。限目。他の人がフォーマットを台無しにせずにエディターでコードを開くことができない場合、あなたも間違っています。これは単純なものである必要があります（）ジョブに適切なツールを使用する場合。結局のところ、私たちはプログラマーです。エディターを構成することは、仕事で毎日ジャンプしなければならないメンタルフープの一部と比較すると、簡単なはずです。
「インデントにタブを使用する利点は、ユーザーが使いやすいタブ幅を使用するようにエディターを構成できることです。」
これは必ずしも本当ではありません。たとえば、Stack ExchangeのQ＆Aエディター（コードを実際のコードエディターにコピーし、そこで編集してからSEに貼り付けるのではなく、コードエディターとしてよく使用されます）を特定のタブ幅に設定してみてください...特にSOでは、貼り付けられたソースコードにタブが含まれている（初心者向けの）質問が多すぎて、結果が混乱することがよくあります。
これは、一般的なタブの使用に関する問題の例です。多くの場合、ソースコードがめちゃくちゃになると、面倒になる状況があります。その結果、スペースとタブの混在に関する問題全体は、いくぶん議論の余地があります、IMO。スペースを使用するだけでeverybodyのほうが簡単です。
これは本当に残念です。 「1つのタブが1つのインデントレベルを意味し、タブの幅が指定されていない」というルールが普遍的に守られていれば、それはとてもエレガントです。しかし、それを持っている一般的な「名前付き」インデントスタイルはありますか？スペースでインデントのステップを指定し、次にスペースでタブの幅を個別に指定する代わりに、これを明示的に実行できるエディターはありますか？
私は1983年にEMACSを学び、最後の年まで若いプログラマーが私のやり方の誤りを説明してくれるまで、タブとスペースを自由に混ぜ合わせました。グループミーティングを行い、ポリシーを変更して、ソースコードのタブを削除しました。
理由は次のとおりです。
- はい、タブとスペースを自由に混在させることができ、EMACSのような高品質のエディターはそれを完全に処理します。 EMACSには、タブを強制終了し、タブを7つのスペースに変換するハッキングバックスペースが適切にあります。 EMACSインデントモードは、4つのスペースを使用して少しインデントし、次にタブ、次にタブと4つのスペース、次に2つのタブなどを使用することが適切であることを理解しています。
- しかし、1990年代にはEMACSのメリットを享受していなかったWINDOWSプログラマーが多数いました。 Visual StudioとTABSでインデントされた唯一のツールです。 8つのスペースでCをインデントするのはばかげているので、タブストップを4に変更しました。これは機能しますが、コードをタブ対応のエディターに取り込むと、恐ろしく見えます。
- スペースは均一に1スペースですが、上記の考察により、他のプログラマーのシステムが適切に設定されているとは限らないことが明らかになりました。
それで、すべてのコードを調べ、それをUNTABIFIEDしました。ああ、恐怖。ああ残念。
これで、各Cファイルの上部に次の小さな行ができました。
/* -*- mode: C++; c-basic-offset: 4; indent-tabs-mode: nil -*- */