📖
ソフトウェア開発業界で最も古く、最も激しい議論の 1 つは、コードをどのようにインデントするかという問題です。タブとスペースのどちらを使用する方が良いでしょうか。一見すると、些細な問題のように思えるかもしれませんが、このジレンマは、何十年にもわたってプログラマーの間で多くの激しい議論を引き起こしてきました。
40 年以上の経験を持つベテランの Microsoft エンジニアである Larry Osterman は、「Microsoft Developer」チャンネルで公開されたでこのトピックに言及し、その中でストレージ デバイスの価格と同様に明らかに無関係な事実がどのように扱われるかを取り上げています。
すべてのバイトがカウントされるとき
「表と表」の歴史スペースの歴史は、ストレージが非常に限られた高価な (非常に高価な) リソースであったプログラミングの初期に遡ります。
オスターマン氏は、大学で勉強して Pascal などの言語でプログラミングをしていたとき、学生が利用できるストレージはわずか 512 キロバイトだったと説明します。これらの制限の下では、すべてのバイトがカウントされます。
スペースを使用すると、各レベルのインデントに約 8 バイトのコストがかかりますが、そのようなスペースをカバーするために 1 バイトを占めるタブは、はるかに効率的なソリューションでした。
この文脈により、コンピューティングの初期における表作成の好みがよりよく理解されます。当時、開発者は、使用可能な限られたメモリにプログラムが確実に収まるように、ストレージ効率を最大化する必要がありました。
ハードドライブを安価にするには…タブの使用を減らしますか?
しかし今日、テクノロジーは劇的に変化しました。ストレージは非常に豊富で経済的です。 1 テラバイトのハード ドライブは比較的少額で購入できるため、各バイトの最適化は過去の懸念事項になりました。
この状況の変化に直面して、オスターマンは他の多くの開発者と同様に考えを変え、「チーム スペース」に加わりました。彼によると、スペースを賭ける主な理由は、コード表示の一貫性です。つまり、スペースを使用すると、各開発者が使用するエディターやソフトウェア構成に関係なく、コードは同じように表示されます。
オスターマン氏にとって、スペースは信頼性の同義語です。スペースは常に同じプレゼンテーションを提供します…一方、タブはインデントの幅を決定する個々の設定に依存するため、さまざまな人やツールで表示するとコードに不整合が生じる可能性があります。
これは、共同プロジェクトでは深刻な問題になります。共同プロジェクトでは、コードの外観が開発者の設定によって大幅に変わるため、エラーが発生したり、コードの保守が困難になったりする可能性があります。
2 つの派閥はある点で合意しています…
オスターマン自身も、賢明な推奨事項で締めくくっています。最も重要なことは、どちらのオプションを選択するかではなく、それらを混合しないようにすることです。
タブとスペースを混在させると、深刻な位置合わせの問題が発生し、コードの解釈と保守が非常に困難になるため、非常に頭の痛い問題が発生する可能性があります。この状況は、将来的にコードの保守を担当する開発者にとって悪夢となる可能性があります。