選択した IDE で「View Right Margin」を有効にすると、デフォルトで 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を使用します。ただし、コードの種類にも依存します。
数年前までは 100 に制限していましたが、現在ではワイドスクリーンが通常使用され、高解像度モニター 120 はラップトップ (私はほとんど使用していません) でも見ることができます。
画面と本を比較するのはあまり良くありません。本の方が縦方向のスペースが多く、画面の方が横方向のスペースが広いからです。私は常に関数を最大に保つようにしています。1 つの可視画面の長さ。
たぶん、80文字はこれらの悪いゲッターチェーンを避けるための良い点でもあります：
object.getFoo().getBar().getFooBar().get ...
80文字に制限すると、誰かがこれらの変数をローカライズしてnullチェックなどを実行する可能性がありますが、ほとんどのプログラマーはそれらを次の行でラップさせる可能性があります。わからない
それに加えて、スターブルーが述べたように、80文字は素晴らしいです。これは間違いなくコーディング標準に入るはずです。
どこかで読んだことをはっきりと覚えています ( Agile Documentationにあったと思います)。最適な可読性のためには、ドキュメントの幅はアルファベット 2 つ分、つまり 60 ～ 70 文字にする必要があります。古い端末の線幅は、その古いタイポグラフィ ルールに一部起因していると思います。
右余白オプションは、コードを印刷する場合にページの幅を表示することを目的としています。以前の投稿では、80 に設定されていると述べていました。これは、GUI がパンチするまでの歴史的な行の長さだったからです。カード。
コードの品質を向上させるために IDE のフォント サイズを大きくするように最近あるブログ (どのブログか思い出せない) で推奨されているのを見たことがあります。シャウター機能。
私の意見では、行が短いほどコードの読み取りとデバッグが容易になるため、行を短く保つようにしています。より良いコードを書くために制限を設定する必要がある場合は、自分に合ったものを選択してください。より長い行は、ページサイズを自由に増やして、ワイドスクリーンでのみコーディングしてください。
一部の人々が他の回答で指摘しているように、80文字の制限の理由は、一部は歴史的（パンチカード、小さな画面、プリンターなど）であり、一部は生物学的です（現在の行を追跡するために、全体を見ることができるのは一般的に良いことです）頭を回す必要なくライン）。
とはいえ、私たちはまだ人間であり、自分の限界を解決するためのツールを構築していることを忘れないでください。文字制限に関する議論全体を無視して、長さに関係なく意味のあるものを書き、行を適切に追跡できる IDE またはテキスト エディターを使用することをお勧めします。タブ対スペースの議論でのインデントとインデントの幅について同じ議論を使用して、インデントマーカー（最も一般的にはタブ）を使用し、それらを表示するように独自のIDEまたはテキストエディターを構成することを提案します彼らにとって最も快適だと思うからです。
1 行あたりの固定文字数に固執すると、ターゲット ユーザー以外のすべての人にとって常に状況が悪化します。とはいえ、コードを共有しない場合は、これまでに. それなら、そもそもこの議論をする理由さえありません。コードを共有したい場合は、あなた (または他の誰か) の理想を強制するのではなく、人々が自分で何を望むかを決定できるようにする必要があります。
私の知る限りでは、80 文字はコマンド ライン エディタとの互換性を維持するためのコーディング標準として使用されています (デフォルトのターミナル幅は通常 80 文字です)。最新の IDE と大画面解像度では、80 文字はおそらく「最適」ではありませんが、多くの開発者にとって、ターミナルで読みやすさを維持することは不可欠です。そのため、80 文字幅がコード幅の事実上の標準としてすぐに置き換えられる可能性は低いです。最後の質問に答えるには、はい、コード幅と、コードの可読性に影響を与えるその他の特性は、コーディング標準で対処する必要があります。