この日と年齢のコードファイルに最大80文字の幅を適用する正当な理由はありますか？
真剣に。 22インチモニターでは、画面の4分の1しかカバーしません。このルールを守るには弾薬が必要です。
制限があってはいけないと言っているのではありません。 80文字は非常に小さいと言っています。
コードを80（または79）列に維持する慣行は、80列のダム端末または80列の印刷物でコードを編集する人々をサポートするために最初に作成されたと思います。これらの要件はほとんどなくなりましたが、80列のルールを維持する正当な理由がまだあります。
- コードを電子メール、Webページ、および書籍にコピーする際の折り返しを回避するため。
- 複数のソースウィンドウを並べて表示する、または並べて表示する差分ビューアを使用する。
- 読みやすさを向上させるため。目を左右にスキャンすることなく、狭いコードをすばやく読み取ることができます。
最後のポイントが最も重要だと思います。ディスプレイは過去数年間でサイズと解像度が大きくなりましたが、目がありません。
80桁のテキストフォーマットの起源は80桁のターミナルよりも前です-IBMパンチカードは 1928 ！これは、米国の鉄道ゲージがローマのイギリスの戦車の車輪の幅によって決定されたという （apocryphal） の物語を連想させます。
私は時々それを少し制限することがありますが、some標準制限があるのが理にかなっているので、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列66行です。
大きな画面の利点を利用して、複数のコードを隣り合わせに配置します。
私から弾薬はもらえません。実際、緊急時にコードコンソールからコードを変更しなければならないまれなケースがまだあるため、変更を確認するのは嫌です。
超長線は読みにくいです。モニターで300文字を取得できるからといって、その行を長くする必要があるわけではありません。 300文字は、選択肢がない場合（パラメーターの束を必要とする呼び出し）を除いて、ステートメントには複雑すぎます。
一般的な規則として80文字を使用していますが、強制すると望ましくない場所に改行が挿入されることを意味する場合は、それを超えます。
80文字以内に収まるように強制するのは、コメントだけです。
個人的に...私はすべての脳力（少しだけ）をコーディングに専念しています。次の機能に時間を費やすことができたときに戻って80文字の制限ですべてを解散するのは苦痛です。はい、Resharperは私のためにそれを行うことができますが、その後、サードパーティ製品がコードレイアウトを決定し、それを変更することを少し驚かせます（「コードを2行HALに分けないでください。HAL？」 ）。
とは言っても、私はかなり小さなチームで仕事をしており、モニターはすべてかなり大きいので、仲間のプログラマーの悩みがそれほど大きな心配ではないことを心配しています。
いくつかの言語は、より多くのコードを提供するために、より長いコード行を奨励しているようです（ショートハンドif thenステートメント）。
2つの20インチ1600x1200モニターがあり、複数のテキストエディターウィンドウを並べて表示できるため、80列に固定します。「6x13」フォント（trad。xtermフォント）を使用すると、80列が480ピクセルとスクロールバーを占有しますこれにより、1600x1200モニターでこのタイプのウィンドウを3つ持つことができます。Windowsでは、Lucida Consoleフォントはこれを行いません（最小使用可能サイズは7ピクセル幅）が、1280x1024モニターは2列を表示します。 HP LP2465 などの1920x1200モニターは3を表示します。また、Visual Studioのさまざまなエクスプローラー、プロパティ、その他のウィンドウのために、少し横にスペースを空けます。
さらに、非常に長いテキスト行は読みにくいです。テキストの場合、最適なのは66文字です。過度に長い識別子は、コードを首尾一貫してレイアウトするのを難しくするため、逆効果になり始めるポイントがあります。優れたレイアウトとインデントは、コード構造に関する視覚的な手がかりを提供し、一部の言語（Pythonの場合は頭に浮かぶ）は、インデントを明示的に使用します。
ただし、Javaおよび.Netの標準クラスライブラリは非常に長い識別子を優先する傾向があるため、これを実行できることを必ずしも保証することはできません。この場合、行を使用してコードをレイアウトする-breaksは、構造を明示的にするのに役立ちます。
Windowsバージョンの「6x13」フォントを取得できることに注意してください Here 。
他の回答はすでに物事をうまくまとめていますが、コードをコピーしてメールに貼り付けたい場合や、コードではなくdiffを貼り付けたい場合も考慮する価値があります。
それは、「最大幅」を持つことが有用なときです。
コードを保守するのはあなただけではありません。
17インチの画面を持っているか、テキストを読むために大きなフォントを必要とするかもしれない次の人。制限はどこかにあり、80文字は以前の画面の制限による慣習です。新しい標準（120）となぜそれ以外のものを使用するのが良いアイデアなのか、それが「Xptフォントで私のモニターに適合するものなのか？」
覚えておいて、すべてのルールには常に例外があるので、特定の行またはコードのブロックがあり、80文字を超えて反逆者になることが理にかなっています。
しかし、最初に考えてみてください。「このコードは80文字以内では生きられないほど悪いのですか？」
これは、この日と年齢でより多くの問題を引き起こす可能性があるのだろうか。 C（およびおそらく他の言語）には、関数名の長さに関するルールがあることに注意してください。そのため、Cコードではわかりにくい名前がよく見られます。良いことは、彼らが多くのスペースを使用しないことです。しかし、C＃やJavaなどの言語のコードを見るたびに、メソッド名が非常に長くなることが多く、コードを80文字の長さに保つことはほぼ不可能になります。コードなどを印刷できるようにする必要がない限り、今日は80文字が有効だと思います。
Linuxのコーディング標準では、80文字の制限を維持するだけでなく、8スペースのインデントも使用します。
推論の一部は、正しいマージンに到達した場合、インデントレベルを別の関数に移動することを検討する必要があるということです。
これにより、インデントの長さに関係なく、ネストされた多くの制御構造を持つコードを読みにくくなるため、コードがより明確になります。
ワイドスクリーンモニターで2つのSxSエディターを使用できるように、幅を100文字程度に制限するのが好きです。もう80文字に制限する理由はないと思います。
他の人が言ったように、（1）印刷と（2）複数のファイルを縦に並べて表示するには最適だと思います。
プロポーショナルフォントを使用します。
私は真剣です。通常、読みやすさや印刷可能性を犠牲にすることなく、1行で100〜120文字の等価性を得ることができます。実際、優れたフォント（例：Verdana）と構文の色付けで読みやすくなっています。数日間は少し奇妙に見えますが、すぐに慣れます。
人々は、長いコード行は複雑になる傾向があると言います。単純なJavaクラス：
public class PlaintiffServiceImpl extends RemoteServiceServlet implements PlaintiffService {
これは94文字の長さで、クラス名は非常に短いです（GWT標準による）。 2行で読むのは難しく、1行で非常に読みやすくなります。それについて実用的であり、したがって「後方互換性」を可能にすると、100文字が正しい幅だと思います。
Macbookの画面の半分以下で快適に収まる100文字にコードを拡張しました。行が長すぎて複雑になり始める前に、おそらく120文字が制限です。複合文や深くネストされた制御構造を推奨する場合、幅を広げすぎたくないでしょう。
右マージンは、 extra method refactoring を実行するよう指示する性質の方法です。
80文字を強制しないということは、最終的にはワードラッピングを意味します。
IMO、最大幅の行に選択された長さは常に適切であるとは限らないため、Wordの折り返しが可能な答えである必要があります。
そして、それは思ったほど簡単ではありません。
Jedit で実装されています
（ソース： jedit.org ） ワードラップを提供します
しかし、それは Eclipseで久しぶりに見逃した ！ （実際には2003年以降）、主に テキストエディターのワードラップ に含まれる理由：
- 折り返し行の情報は、テキストビューアー、コードナビゲーション、垂直ルーラー用です。
- 行の移動、行番号付けルーラー列、現在の行の強調表示、ファイルの保存などの機能には、折り返されていない行の情報が必要です。
私は単純な理由で80文字近くに物事を抑えようとします：それ以上だと、コードが複雑になりすぎます。過度に詳細なプロパティ/メソッド名、クラス名などは、簡潔なものと同じくらいの害を引き起こします。
私は主にPythonコーダーなので、これにより2つの制限が生じます。
- 長いコード行を書かないでください
- インデントしすぎないでください
2つまたは3つのレベルのインデントに達すると、ロジックが混乱します。同じページに単一のブロックを保持できない場合、コードは複雑すぎて覚えにくいものになります。 1行を80文字以内に収められない場合、行は非常に複雑になります。
Pythonでは読みやすさを犠牲にして比較的簡潔なコード（codegolfを参照）を書くのは簡単ですが、読みやすさを犠牲にして冗長コードを書くのはさらに簡単です。ヘルパーメソッドは悪いことではありません。過剰な抽象化は問題になる可能性がありますが、それはプログラミングのもう1つの課題です。
Cのような言語で疑問がある場合は、別の関数を呼び出してジャンプするオーバーヘッドが必要ない場合は、ヘルパー関数を作成してインライン化します。ほとんどの場合、コンパイラーは物事を賢く処理します。
これにはすでに多くの良い答えがありますが、あなたのIDEで左側にファイルのリストがあり、右側に関数のリストがあるかもしれません。構成）。
コードは環境の一部にすぎません。
はい、今日でも私たちの一部は端末でコーディングしています（大部分は端末エミュレータ）。ディスプレイでは80文字しか表示できません。したがって、少なくとも私が行うコーディングに関しては、80文字のルールを高く評価しています。
私は実際に自分のコードについても同様のルールに従いますが、コードをA4ページに印刷するためだけです。80カラムは、希望するフォントサイズに適切な幅です。
しかし、それは個人的な好みであり、おそらくあなたが望んでいたものではありません（弾薬を逆にしたいので）。
限界の背後にある理由に疑問を呈しませんか-真剣に、だれもそれがそうである正当な理由を思い付くことができないなら、あなたはそれをあなたのコーディング標準から削除する良いケースがあります。
私は一日中並べて比較していますが、22インチのモニターはありません。私がこれまでにそうするかどうかはわかりません。もちろん、これは、矢印コーディングと300文字の行を楽しんでいる書き込み専用のプログラマーにはほとんど関心がありません。
行を80列未満にしようとしています。最も強力な理由は、コマンドラインで作業しているときにgrepとlessを使用してコードを参照することが多いためです。私は、端末が長いソース行を分割する方法が本当に好きではありません（結局、その仕事のために作られていないのです）。もう1つの理由は、すべてが行に収まり、エディターによって壊れていない方が見た目が良いことです。たとえば、長い関数呼び出しのパラメータを、互いに下にうまく配置して、同様のものを配置します。
生徒に80列に絞るように強制するため、コードを印刷してマークアップできます。
そして約17年前、私は Noweb を使用してすべてを始め、88列がTeXを使用してうまく印刷されたドキュメントに収まるので、自分のコードを88列に拡張しました。
私は2つのスペースだけでインデントしますが、余分な部屋は素晴らしいです。
80文字を超えることはあなたがすることです ながら コーディングではなく、その後。もちろんコメントも同じです。ほとんどのエディターは、80文字の制限がどこにあるかを確認するのに役立ちます。
（これは少しOTかもしれませんが、Eclipseには、保存するときにコードをフォーマットするオプションがあります（必要なルールに従って）。これは、最初は少しおかしいですが、しばらくすると、生成されたコードと同じように、フォーマットはあなたの手にありません。）
これら のいずれかがあれば、この議論はありません！ ;-)
しかし、真剣に人々が彼らの答えで提起した問題は非常に合法です。しかし、元のポスターは制限に反対していませんでした。80桁が少なすぎるというだけです。
コードスニペットをメールで送信することにはいくつかのメリットがあります。しかし、ほとんどの電子メールクライアントが書式設定済みのテキストに対して行う悪いことを考えると、行の折り返しは問題の1つに過ぎないと思います。
印刷に関しては、通常、100文字の行がvery印刷ページに快適に収まることがわかります。
最近調査を行いました。ほとんどすべての人がgnome-terminal内でvimを使用し、垂直分割を行うと、列数は標準フォントサイズおよび画面解像度1280x1024として78になります。
そのため、列数が（約）75文字のコーディング標準に全員が同意しました。大丈夫です。
私はまだ、視覚的な部分で制限は制限されていないと思います。確かに、モニターと解像度は最近では1行にさらに多くの文字を表示するのに十分な大きさですが、読みやすさは向上しますか？
制限が実際に適用される場合、コードを再考し、すべてを1行に入れるためにnotを再検討することも正当な理由です。インデントの場合も同じです。多くのレベルが必要な場合は、コードを再考する必要があります。