この日と年齢で、コードファイルに最大80文字の幅を強制する正当な理由はありますか？[閉まっている]

真剣に。22インチモニターでは、画面の4分の1しかカバーしません。このルールを回避するには弾薬が必要です。

制限があるべきではないと言っているのではありません。80文字は非常に小さいです。

80（または79）列にコードを保持する習慣は、80列のダム端末または80列の印刷物でコードを編集する人々をサポートするために最初に作成されたと思います。これらの要件はほとんどなくなりましたが、80列のルールを維持する正当な理由はまだあります。

• コードを電子メール、Webページ、および本にコピーするときに折り返しを回避するため。
• 複数のソースウィンドウを並べて表示するか、並べて比較ビューアを使用します。
• 読みやすさを向上させるため。細いコードは、目を左右にスキャンすることなくすばやく読み取ることができます。

最後のポイントが一番重要だと思います。過去数年でディスプレイのサイズと解像度は大きくなっていますが、目は大きくありません。

80カラムのテキストフォーマットの起源は、80カラムターミナルより前です。IBMパンチカードは1928年にさかのぼります。これは、米国の鉄道のゲージがローマイギリスの戦車の車輪の幅によって決定された（黙示録的な）物語を連想させます。

私は時々それをややこしいことに気づきますが、いくつかの標準的な制限があるのは理にかなっているので、80カラムです。

これはSlashdotでカバーされている同じトピックです。

そして、これが昔ながらのFortranの声明です。

最近の80文字はとんでもない制限です。任意の文字制限に従ってではなく、意味のある場所でコード行を分割します。

22インチのワイドスクリーンモニターを持っていないすべての人のために、それを行う必要があります。個人的には、17インチの4：3モニターで作業していますが、十分に広いと感じています。ただし、これらのモニターも3つあるので、使用可能な画面スペースはまだたくさんあります。

それだけでなく、人間の目は実際には、行が長すぎるとテキストを読むのに問題があります。どのラインにいるのか迷うのは簡単です。新聞は横幅が17インチ（またはそれと似ている）ですが、ページ全体に新聞が書かれているのはわかりません。雑誌やその他の印刷物についても同様です。列を狭くしておくと、実際に読みやすくなります。

わずかなバリエーションで繰り返される一連のステートメントがある場合、それらが行にグループ化されて差異が垂直方向に揃うようにすると、類似性と差異が見やすくなります。

次のコードは、複数行に分割した場合よりもはるかに読みやすくなっています。

switch(Type) {
case External_BL:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
case External_BR:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
case External_TR:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case External_TL:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case Internal_BL:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case Internal_BR:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case Internal_TR:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
case Internal_TL:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
}

更新：コメントの中で、これは上記を行うためのより簡潔な方法であることが示唆されています：

switch(Type) {
  case External_BL: dxDir = - 1; dyDir = - 1; break;
  case External_BR: dxDir = + 1; dyDir = - 1; break;
  case External_TR: dxDir = + 1; dyDir = + 1; break;
  case External_TL: dxDir = - 1; dyDir = + 1; break;
  case Internal_BL: dxDir = + 1; dyDir = + 1; break;
  case Internal_BR: dxDir = - 1; dyDir = + 1; break;
  case Internal_TR: dxDir = - 1; dyDir = - 1; break;
  case Internal_TL: dxDir = + 1; dyDir = - 1; break;
}
mpstrd["X"] = pt1.x + dxDir * RadialClrX;
mpstrd["Y"] = pt1.y + dyDir * RadialClrY; 

80列に収まるようになりましたが、私の主張はまだ残っていると思います。悪い例を選びました。それでも、行に複数のステートメントを配置すると読みやすさが向上することを示しています。

等幅フォントをデフォルトサイズで印刷すると、（A4用紙で）80カラムx 66行になります。

大きな画面の利点を利用して、複数のコードを並べて配置しています。

あなたは私から弾薬をもらえません。実際、緊急時にコードをテキストコンソールから変更する必要があるまれなケースがまだあるので、それが変更されるのを見るのは嫌です。

超長い線は読みにくくなります。モニターで300文字を取得できるからといって、行をそれほど長くする必要があるわけではありません。また、300文字は、選択の余地がない限り（ステートメントのパラメーター全体を必要とする呼び出しの場合）、ステートメントにとって複雑すぎます。

原則として80文字を使用しますが、強制すると望ましくない場所に改行が挿入される場合は、それを超えます。

私が80文字以内に留まることを強制する唯一のことは、私のコメントです。

個人的に...私は正しいコーディングにすべての頭脳の力（ほとんど何もない）を費やしています、次の機能に時間を費やすことができるときに戻ってすべてを80文字の制限で分割する必要があるのは苦痛です。はい、Resharperは私のためにそれを行うことができると思いますが、サードパーティ製品が私のコードレイアウトを決定し、それを変更していることに少し気が動転します（「コードを2行HALに分割しないでください。HAL？」 ）。

とは言っても、私はかなり小さなチームで作業しており、すべてのモニターはかなり大きいので、他のプログラマーが何を気にしているかについて心配することは、それに関しては大きな問題ではありません。

一部の言語では、見返りを増やすために、より長いコード行を奨励しているようです（if if thenステートメント）。

2つの20インチ1600x1200モニターがあり、複数のテキストエディターウィンドウを横に並べて表示できるため、80カラムを使用しています。「6x13」フォント（従来のxtermフォント）を使用すると、80カラムは480ピクセルとスクロールバーになります。とウィンドウの境界線。これにより、1600x1200のモニターにこのタイプのウィンドウを3つ作成できます。Windowsでは、Lucida Consoleフォントはこれを完全に実行しません（最小使用可能サイズは7ピクセル幅です）が、1280x1024モニターは2つの列とHP LP2465などの1920x1200モニターには3が表示されます。また、Visual Studioのさまざまなエクスプローラー、プロパティ、およびその他のウィンドウのために、横に少し余裕ができます。

さらに、非常に長いテキスト行は読みにくいです。テキストの場合、最適なのは66文字です。識別子が長すぎると、コードを首尾一貫してレイアウトすることが難しくなるため、逆効果になります。優れたレイアウトとインデントは、コード構造に関する視覚的な手掛かりを提供し、一部の言語（Pythonが頭に浮かびます）は、このためにインデントを明示的に使用します。

ただし、Javaと.Netの標準クラスライブラリは、非常に長い識別子が優勢である傾向があるため、これを実行できるとは限りません。この場合でも、改行を含むコードのレイアウトは、構造を明示的にするのに役立ちます。

あなたが「6x13と」フォントのWindows版を入手できることに注意してくださいここで。

長いコード行は複雑になる傾向があると人々は言います。単純なJavaクラスについて考えてみましょう。

public class PlaintiffServiceImpl extends RemoteServiceServlet implements PlaintiffService {

これは94文字の長さで、クラス名は（GWT標準では）非常に短くなっています。2行で読むのは難しく、1行で非常に読みやすいです。それについて実用的であり、したがって「後方互換性」を可能にするので、100文字が適切な幅だと思います。

他の回答はすでにうまくまとめられていますが、コードをコピーしてメールに貼り付けたい場合や、コードでない場合はdiffを検討する価値もあります。

これは、「最大幅」が役立つ場合です。

コードを保守するのはあなただけではありません。

次の人は、17インチの画面を持っているか、テキストを読むために大きなフォントが必要になる可能性があります。制限はどこかにある必要があり、80文字は以前の画面の制限による規則です。新しい標準（120）とそれ以外の方法を使用するのが良いのはなぜですか。「Xptフォントでモニターに適合します」

すべてのルールには常に例外があるので、80文字を超えるコードを特定の行またはブロックにすると、反抗者になることを忘れないでください。

しかし、最初に時間をかけて「このコードは80文字以内に収まらないほど本当に悪いのか」と考えてください。

Linuxコーディング標準では、80文字の制限を維持するだけでなく、8つのスペースインデントも使用します。

理由の1つは、適切なマージンに達した場合は、インデントレベルを別の関数に移動することを検討する必要があるということです。

インデントの長さに関係なく、ネストされた制御構造が多数含まれているコードを読み取るのが難しいため、これによりコードがより明確になります。

Macbookの画面の半分以下に収まるように、コードを100文字に広げました。行が長くなりすぎて複雑になり始める前に、120文字がおそらく制限です。幅を広げすぎたくない場合は、複合ステートメントと深くネストされた制御構造を推奨します。

右マージンは、追加のメソッドリファクタリングを実行するように指示する自然の方法です。

これがこの時代にもっと問題を引き起こすのではないかと思います。C（および場合によっては他の言語）には、関数名の長さに関する規則があることに注意してください。したがって、Cコードでは、非常に理解しにくい名前がよく見られます。良いことは、彼らが多くのスペースを使用しないことです。しかし、C＃やJavaなどの言語でコードを見るたびに、メソッド名が非常に長くなることがよくあります。そのため、コードを80文字の長さに保つことはほぼ不可能です。コードなどを印刷する必要がない限り、今日は80文字は有効ではないと思います。

雇用主向けのコーディングガイドラインの作成者として、行の長さを80から132に増やしました。なぜこの値なのですか？まあ、他の人が指摘したように、80は多くの古いハードウェア端末の長さです。そして、132も同様です。端末がワイドモードのときの線幅です。どのプリンタでも、ワイドモードでフォントを圧縮してハードコピーを作成できます。

80にとどまらない理由は、むしろ

• 識別子の意味を持つ長い名前を好む
• コードをより持っているので、（彼らは悪いです、彼らは有用な情報を非表示！あなたはそれを信じていない場合は、「ディープ・Cの秘密」でリンデンDERピーター・バンを依頼）Cでの構造体と列挙型のためのtypedefを気にしないstruct FOO func(struct BAR *aWhatever, ...)typedefの狂信者のコードよりもを。

そして、これらのルールの下では、80文字/行は、私の目が許容できると考えるよりも頻繁に醜い行の折り返しを引き起こします（主にプロトタイプと関数定義で）。

他の人が言ったように、（1）印刷と（2）複数のファイルを縦に並べて表示するのが最適だと思います。

幅を100文字程度に制限して、ワイドスクリーンモニターで2つのSxSエディターを使用できるようにします。正確に80文字に制限する理由はもうないと思います。

プロポーショナルフォントを使用します。

私は真剣です。通常、読みやすさや印刷性を犠牲にすることなく、1行で100〜120文字相当を取得できます。実際、優れたフォント（Verdanaなど）と構文の色分けを使用すると、読みやすくなります。数日間少し奇妙に見えますが、すぐに慣れます。

単純な理由で、80文字近くに抑えるようにしています。それを超えると、コードが複雑になりすぎます。過度に詳細なプロパティ/メソッド名、クラス名などは、簡潔なものと同じくらいの害をもたらします。

私は主にPythonコーダーなので、2つの制限があります。

1. 長いコード行を記述しないでください
2. インデントしすぎないでください

2つまたは3つのレベルのインデントに達し始めると、ロジックが混乱します。同じページに1つのブロックを保持できない場合、コードが複雑になり、覚えにくくなります。1行を80文字以内に収められない場合、その行は非常に複雑になっています。

Pythonでは、読みやすさを犠牲にして比較的簡潔なコード（codegolfを参照）を書くのは簡単ですが、読みやすさを犠牲にして詳細コードを書く方が簡単です。ヘルパーメソッドは悪いことでも、ヘルパークラスでもありません。過度の抽象化は問題になる可能性がありますが、それはプログラミングのもう1つの課題です。

Cのような言語で疑わしい場合は、ヘルパー関数を記述し、別の関数を呼び出してジャンプバックするオーバーヘッドが必要ない場合は、それらをインライン化します。ほとんどの場合、コンパイラーがインテリジェントに処理します。

これにはすでに良い答えがたくさんありますが、IDEの左側にファイルのリスト、右側に関数のリスト（またはその他の構成）がある場合があることに言及する価値があります。

コードは環境の一部にすぎません。

80文字を強制しないということは、最終的にワードラップを意味します。
IMO、最大幅の線に選択された長さは常に適切であるとは限らず、ワードラッピングが可能な答えになるはずです。
そして、それは思ったほど簡単ではありません。

jeditで実装されています_{（ソース：jedit.org）}
ワードラップを提供ています

しかし、それはひどい時代の食でひどく見逃されている！（実際には2003年以降）、主にテキストエディターのワードラップが含まれるため：

• 折り返された行の情報は、テキストビューア、コードナビゲーション、垂直定規用です。
• 行の折り返し、行番号付けルーラー列、現在の行の強調表示、ファイルの保存などの機能には、折り返されていない行情報が必要です。

実際、自分のコードについても同様のルールに従いますが、コードをA4ページに印刷するためです。80カラムは、希望するフォントサイズの幅とほぼ同じです。

しかし、それは個人的な好みであり、おそらくあなたが求めていたものではありません（弾薬を逆方向に移動させたいため）。

制限の背後にある理由に疑問を投げかけないでください-真剣に、だれもそうであるという正当な理由をだれも見つけられない場合は、コーディング標準からそれを削除することについての正当な理由があります。

私は1日中並べて比較しています。22インチのフリークモニターはありません。私がするかどうかはわかりません。もちろん、これは、矢印コーディングと300文字の行を楽しむ書き込み専用のプログラマーにはほとんど関係ありません。

はい、この時代でさえ、私たちの一部は端末でコーディングを行っているため（大抵は端末エミュレータ）、ディスプレイには80文字しか表示できません。したがって、少なくとも私が行うコーディングでは、80文字のルールに本当に感謝しています。

私はまだ視覚的な制限はないと思います。確かに、モニターと解像度は今日では1行にさらに多くの文字を表示するのに十分な大きさですが、読みやすさは向上しますか？

制限が実際に適用される場合は、コードを再考してすべてを1行にまとめないことも適切な理由です。インデントについても同じです。多くのレベルが必要な場合は、コードを再考する必要があります。

80文字での改行は、コーディング中に行うものであり、その後ではありません。もちろんコメントも同じです。ほとんどのエディターは、80文字の制限がどこにあるかを確認するのに役立ちます。

（これは少しOTかもしれませんが、Eclipseには、保存するときにコードをフォーマットするオプションがあります（必要なルールに従って）。これは最初は少しおかしなことですが、しばらくすると、生成されたコードと同じようにフォーマットすることはできません。）

これらのいずれかがあった場合、このディスカッションはありません！;-)

しかし真剣に人々が答えで提起した問題はかなり正当です。ただし、元のポスターは制限に反対するものではなく、80列が少なすぎることを示しています。

コードスニペットのメール送信の問題にはいくつかのメリットがあります。しかし、ほとんどのメールクライアントが事前にフォーマットされたテキストに対して行う邪悪なことを考えると、行の折り返しは問題の1つに過ぎないと思います。

印刷に関して、私は通常、100文字の行が印刷されたページに非常に快適に収まることを発見しました。

私は自分の行を80列未満に保つようにしています。最も強い理由は、コマンドラインで作業しているときに自分のコードを使用したり参照しgrepたりlessすることが多いためです。端末が長いソース行を壊してしまうのは本当に嫌いです（結局、その仕事のために作られたわけではありません）。もう1つの理由は、すべてが行に収まり、エディターによって中断されない場合に、見栄えがよくなることです。たとえば、長い関数呼び出しのパラメータを、お互いに類似したものの下にうまく配置します。