最適なコード幅の研究？

選択したIDEで「右マージンの表示」を有効にすると、デフォルトで80文字になる可能性があります。私は、数年前の会社の標準であったことを除いて、それを120に変更する傾向があり、他の会社が別の方法でそれを行うように指示していません。

私の質問は、コードの可読性の最適な最大幅である80文字を実際に示している研究はありますか、またはこの値は単なる「これまでどおり」であり、それがなぜそのようになっているのか本当に誰にもわかりませんか？そして、コード行の幅はコーディング標準の一部である必要がありますか？

実際には、80桁のものがDOSに先行しています。これは、80カラムのデバイスであったカードパンチからのものです。

そして、ある種のOPの質問に答えるために、1つの「研究」が約600年間続いています-印刷された本。これらは何世紀にもわたって、読みやすさを第一に考えて、現在のテキストの平均行長が約60文字になる位置に進化しました。読みやすくするために、マージンを狭くしてください。

後でソフトウェアを保守し、80文字の制限に固執する必要のあるプログラマーを憐れんでください。

80を選ぶ理由：

• ラップトップで大きなフォントで読むことができます

• 比較のために2つのバージョンを並べて配置するためのスペースを残す

• IDEのナビゲーションビュー用のスペースを残します

• 任意に改行せずに印刷します（電子メール、Webページなどにも適用されます）

• 1行で複雑さを制限

• インデントを制限し、メソッド/関数の複雑さを制限します

はい、それはコーディング標準の一部であるべきです。

勉強はしていませんが、私の経験を紹介します。

テキストを処理するとき、水平スクロールが面倒であることがわかりました。コードが使用される環境を調べ、そのコンテキストに基づいて幅の標準を設定します。

たとえば、XWindowsのEmacsで作業していたとき、常に2つのEmacsウィンドウが並んでいるとうまくいきました。これで80文字に制限されたため、これが私の最大行長でした。

ある時点で、私は1920x1200画面のVisual Studioで作業しました。すべてのツールウィンドウを片側にドッキングして、最大化します。約100文字で、2つのエディタウィンドウを並べて表示するのに十分なスペースがありました。

また、最長の行は、長いパラメーターリストを使用したメソッド呼び出しからのものであることがわかりました。これはコードの匂いになることがあります。おそらくメソッドをリファクタリングする必要があります。

あなたとあなたの同僚が高解像度の画面と鋭い視力を持っているなら、必ず小さなフォントと長い行を使用してください。逆に、短い行が必要になる場合があります。

会社が別段の記載がない限り、私は通常120-150を使用します。ただし、コードの種類にも依存します。

• （ほとんど）1行で複数のステートメントを使用することはない
• 長い行（> 12）を使用するのは、見た目が似ている行が整列していて切れない場合のみです。
• 私はいつも十分なスペース/括弧などを使います
• 短い名前よりも長い変数名を好む

数年前までは100に制限していましたが、現在はワイドスクリーンが通常使用されており、高解像度モニター120はラップトップ（ほとんど使用していません）でも見ることができます。

ブックには縦方向のスペースが多く、スクリーンには横方向のスペースがあるため、スクリーンと本の比較はあまり良くありません。私は常に機能を最大に保つようにしています。1つの目に見える画面。

たぶん80文字は、これらの悪いゲッターチェーンを回避するための良い点でもあります。

object.getFoo().getBar().getFooBar().get ...

80文字に制限すると、誰かがこれらの変数をローカライズしてnullチェックなどを行うかもしれませんが、ほとんどのプログラマーはそれらを次の行に折り返すようにします。知りません

それに加えて、スターブルーが言及したように80文字は素晴らしいです。これは間違いなくコーディング標準に入るはずです。

ハードウェアの制限、およびコードと自然言語の読み方の違いを無視すると、行を約80文字に制限する3つの主な理由がわかります。

1. 人間の眼球は丸く、実際には狭くも広くもありません。解像度のほとんどは中央にあります。一度に何時間も読む場合は、必要に応じて1つのスクロールバーを使用して、短い弧で目をスイープする方がはるかに快適です。コードの読みやすさに固有の正式な調査については知りませんが、自分の観察によると、モニターが2フィート離れており、テキストのサイズが10ptの等幅フォントであり、100文字で水平フィールドの約1/3を占めています。視力、または約60度（すべての目の解像度がである30度の範囲外）。
2. ほとんどの人は仕事で大きなモニターを使用しているため、前後にクリックしなくても複数のものを見ることができます。
3. 短い行ほど複雑さが少なくなるため、開発者はコードをよりわかりやすい単位に分割する必要があります。

私はどこかで読んだことをはっきりと覚えています（アジャイルドキュメンテーションにあったと思います）最適な読みやすさのために、ドキュメントの幅は約2つのアルファベット、または60-70文字であるべきです。古いターミナルの線幅は、その古い活版印刷の規則に一部起因していると思います。

右余白オプションは、コードを印刷する場合にページの幅を表示することを目的としており、以前に投稿されていたように、80に設定されていたため、GUIの前までは行の長さがずっと前にあったため、パンチまで戻りました。カード。

最近、いくつかのブログ（IDEのフォントサイズを大きくすることはできません）で、コードの品質を向上させるためにIDEフォントサイズを増やすことを推奨しています。その背後にあるロジックは、画面に表示されるコードが少ない場合、短い行を記述し、シャワー機能。

私の意見では、短い行はコードの読み取りとデバッグを容易にするので、行を短くするようにしています。制限を設定して自分でより良いコードを作成する必要がある場合は、機能するものを選択してください。長い行は、ワイドスクリーンでのみページサイズとコードを増やしてもかまいません。

一部の人々が他の回答で指摘しているように、80文字の制限の理由は、部分的に歴史的（パンチカード、小さな画面、プリンターなど）であり、部分的に生物学的（あなたがどの行にいるかを追跡するために、全体を見ることができるのは一般的に良いことです）頭を回す必要がないライン）。

とは言っても、私たちはまだ人間であり、私たち自身の限界を解決するためのツールを構築していることを忘れないでください。文字制限に関する議論全体を無視し、長さに関係なく意味のあるものを書くだけで、行を適切に追跡できるIDEまたはテキストエディターを使用することをお勧めします。タブとスペースの議論のインデントに同じ引数を使用し、インデントの幅をどの程度にするかを提案します。インデントマーカー（最も一般的にはタブ）を使用して、独自のIDEまたはテキストエディターを構成して表示するように提案します。彼らが彼らに最も快適であると思うとき。

1行あたりの文字数が固定されていると、対象となる視聴者以外の全員にとって常に事態が悪化します。とはいえ、コードを共有することは決してないでしょう。そのため、このディスカッションを開始する理由さえまったくありません。コードを共有したい場合は、自分（または他の人）の理想を彼らに強制するのではなく、人々が自分で何を望むかを決定させるべきでしょう。

私の知る限りでは、80文字はコマンドラインエディタとの互換性を維持するためのコーディング標準として使用されています（デフォルトの端末幅は通常80文字です）。最新のIDEと大きな画面解像度では、80文字はおそらく「最適」ではありませんが、多くの開発者にとって、ターミナルでの読みやすさを維持することは不可欠です。そのため、80文字幅がコード幅のデファクトスタンダードとしてすぐに置き換えられる可能性はほとんどありません。そして、最後の質問に答えるには、はい、コード幅と、コードの可読性に影響を与えるその他の特性は、コーディング標準で対処する必要があります。