最適なコード幅の研究？
選択したIDEで「View Right Margin」を有効にすると、デフォルトで80文字になります。それ以外の理由で120に変更する傾向があります。私は数年前にいた会社の標準であり、他の会社は私にそれを違うやり方で行うように言っていません。
私の質問は、実際に80文字がコードの読みやすさの最適な最大幅であることを示す研究はありますか、またはこの値は「常にそうである」だけで、なぜそうなのか誰も本当に知りませんか？また、コード行の幅はコーディング標準の一部である必要がありますか？
実際に、80カラムはDOSよりもずっと前にあります。 80カラムのデバイスであるカードパンチに由来します。
そして、OPの質問に一種答えるために、1つの「研究」が約600年間続いています-印刷された本です。これらは、何世紀にもわたって読みやすさを第一に考えて進化しており、現在のテキストの平均行長は約60文字です。そのため、読みやすくするために、マージンを狭くしてください。
後でソフトウェアを保守し、80文字の制限を守らなければならないプログラマを容赦してください。
80を好む理由：
ラップトップでより大きなフォントで読み取り可能
比較のために2つのバージョンを並べて置くスペースを残します
IDEのナビゲーションビュー用のスペースを残します
Arbitrarily意的に行を分割せずに印刷します（電子メール、Webページなどにも適用されます）
1行で複雑さを制限
インデントを制限し、メソッド/機能の複雑さを制限します
はい、それはコーディング標準の一部であるべきです。
私は勉強していませんが、自分の経験を伝えます。
テキストを処理するときに水平スクロールは退屈ですであることがわかりました。コードが使用される環境を見て、そのコンテキストに基づいて幅の標準を設定します。
たとえば、私がXWindows上のEmacsで作業したとき、2つのEmacsウィンドウside-by-sideが常に機能していました。そのため80文字に制限されていたため、それが私の最大行長でした。
ある時点で、私はVisual Studioで1920x1200の画面で作業しました。すべてのツールウィンドウを片側にドッキングして、最大化を維持します。約100文字で2つのエディターウィンドウを並べて表示するための十分なスペースが残っていました。
また、最も長い行は長いパラメーターリストを使用したメソッド呼び出しから来ることもわかりました。これは時々code smellです：おそらくメソッドはrefactoredであるべきです。
あなたとあなたの共同プログラマーが高解像度の画面と鋭い視力を持っている場合、必ず小さなフォントと長い線を使用してください。逆に、短い行が必要になる場合があります。
会社が別段の説明をしない限り、通常120〜150を使用します。ただし、コードの種類にも依存します。
- 私は（ほとんど）1行で複数のステートメントを使用しない
- 長い行（> 12）を使用するのは、似たような行を整列でき、分割できない場合のみです。
- 私は常に十分なスペース/括弧などを使用します
- 短い名前よりも長い変数名を好む
数年前までは100台に制限されていましたが、現在では通常ワイドスクリーンが使用され、ラップトップ（ほとんど使用していません）でも高解像度モニター120を見ることができます。
画面と本の比較は、本の縦方向のスペースが大きく、画面の横方向のスペースが大きいため、あまり良くありません。私は常に関数を最大にしようとします。 1つの長い画面。
たぶん80文字は、これらの悪いゲッターチェーンを回避する良い点でもあります。
object.getFoo().getBar().getFooBar().get ...
80文字に制限すると、誰かがこれらの変数をローカライズし、nullチェックなどを行う可能性がありますが、ほとんどのプログラマーは次の行にラップする可能性があります。知りません
それに加えて、スターブルーが言及したように80文字が素晴らしいです。これは間違いなくコーディング標準に含まれるはずです。
最適な読みやすさのためにドキュメントの幅は約2アルファベット、つまり60〜70文字でなければならないことをはっきりと覚えています（ Agile Documentation にあったと思います）。古い端末の線幅は、その古い誤植の規則に一部起因していると思います。
右余白オプションは、コードを印刷する場合にページの幅を表示することを目的としており、以前に投稿された80に設定されていると述べています。カード。
私は最近、いくつかのブログで推奨事項を見てきました（どのブログを覚えていない）あなたを増やすIDEコード品質を改善するためにフォントサイズ、その背後にあるロジックは、より少ないコード画面には、短い行とシューター関数を記述します。
私の意見では、短い行はコードの読み取りとデバッグを容易にしますので、より良いコードを書くために制限を設定する必要がある場合は、行を短くしてください長い画面では、幅の広い画面でのみページサイズとコードを増やすことができます。
ハードウェアの制限、およびコードの読み方と自然言語の違いを無視すると、行を約80文字に制限する3つの主な理由がわかります。
- 人間の眼球は丸く、実際には狭くも広くもなく、そして その解像度のほとんどは中央にあります 。一度に数時間読む場合、必要に応じて1つのスクロールバーを使用して、短い弧を描いて目をスイープする方がはるかに快適です。コードの可読性に固有の正式な研究については知りませんが、2フィート離れたモニターで、10ポイントのモノスペースフォントのサイズのテキストで、私自身の観察から、100文字が私の水平フィールドの約1/3を占めます視力、または約60度（ すべての目の解像度が30度程度の場合 ）。
- ほとんどの人は仕事中に大きなモニターを使用して、前後をクリックすることなく複数のものを見ることができるようにします。
- 短い行には複雑さが少ないため、開発者がコードをより消化しやすい単位に分割することが望まれます。
一部の人々が他の回答で指摘したように、80文字の制限の理由は部分的に歴史的（パンチカード、小さな画面、プリンタなど）であり、部分的に生物学的です（あなたがいる行を追跡することは一般的に全体を見ることができるのは良いことです頭を回す必要のない線）。
とはいえ、私たちはまだ人間であり、自分の限界を解決するためのツールを構築していることを覚えておいてください。文字の制限に関する議論全体を無視し、長さに関係なく意味のあるものだけを書き、IDEまたはテキストエディターを使用して、行を適切に追跡できるようにすることをお勧めします。タブとスペースの議論でのインデントに同じ引数を使用し、インデントの幅を決定する必要があるだけでなく、インデントマーカー（最も一般的にはタブ）を使用し、自分でIDEまたは、テキストエディタを使用して、最も快適だと思うものを表示します。
1行あたりの文字数を固定すると、対象となる視聴者以外のすべての人にとって常に事態が悪化します。つまり、コードを決して共有しないのであれば。そもそもこの議論をする理由さえありません。コードを共有したい場合は、おそらくあなた（または他の誰か）の理想を強制するのではなく、人々が自分で何を望むかを決定できるようにする必要があります。
私の知る限り、80文字は、コマンドラインエディターとの互換性を維持するためのコーディング標準として使用されます（デフォルトの端末幅は通常80文字です）。最新のIDEと大画面解像度では、80文字はおそらく「最適」ではありませんが、多くの開発者にとっては、端末で読みやすさを維持することが不可欠です。そのため、コード幅の事実上の標準として、すぐに80文字幅が置き換えられることはまずありません。最後の質問に答えるために、はい、コードの幅とコードの可読性に影響するその他の特性は、コーディング標準で対処する必要があります。