text-editor - 現在、コードファイルの最大幅を 80 文字にする正当な理由はありますか?

Question

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

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

score 278 · Accepted Answer

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

コードを電子メール、Web ページ、書籍にコピーする際の折り返しを避けるため。
複数のソースウィンドウを並べて表示するか、並べて表示する差分ビューアを使用します。
可読性を向上させるため。狭いコードは、目を左右にスキャンしなくてもすばやく読み取ることができます。

最後の点が最も重要だと思います。ここ数年でディスプレイのサイズと解像度は向上しましたが、目はそうではありません。

score 82 · Accepted Answer

80 桁のテキスト形式の起源は、80 桁の端末よりも前です。IBM のパンチカードは1928 年にさかのぼり、その遺産は1725 年の紙テープにまでさかのぼります。これは、アメリカの鉄道の軌間がローマ時代の英国の戦車の車輪の幅によって決定されたという(外典の)話を思い起こさせます。

少し窮屈だと思うこともありますが、標準的な制限を設けるのは理にかなっているので、80列です。

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

そして、これは昔ながらの Fortran ステートメントです。

score 58 · Accepted Answer

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

score 36 · Accepted Answer

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

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

score 26 · Accepted Answer

わずかなバリエーションで繰り返される一連のステートメントがある場合、それらが行にグループ化されて相違点が垂直に整列する場合、類似点と相違点を簡単に確認できます。

以下は、複数行に分割した場合よりもはるかに読みやすいと思います。

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列に収まっていますが、私の主張はまだ残っていると思います。悪い例を選んだだけです。1行に複数のステートメントを配置すると、読みやすさが向上することを示しています。

score 22 · Accepted Answer

等幅フォントをデフォルトサイズで印刷すると (A4 用紙で) 80 列 x 66 行になります。

score 16 · Accepted Answer

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

私から弾薬を受け取ることはありません。実際、緊急時にテキストコンソールからコードを変更する必要があるというまれなケースがまだ見られるため、変更されるのは嫌です。

score 14 · Accepted Answer

非常に長い行は読みにくくなります。モニターで 300 文字を表示できるからといって、行をそれほど長くする必要があるわけではありません。300 文字は、選択の余地がない限り (大量のパラメーターを必要とする呼び出し)、ステートメントとしても複雑すぎます。

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

score 9 · Accepted Answer

80 文字以内に収まるように強制するのは、コメントだけです。

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

とは言うものの、私はかなり小さなチームで働いており、モニターはすべてかなり大きいので、仲間のプログラマーを悩ませることについて心配することは、それほど大きな問題ではありません.

一部の言語では、費用対効果を高めるために、より長いコード行を推奨しているようです (省略形の if then ステートメント)。

score 7 · Accepted Answer

私は 20 インチの 1600x1200 モニターを 2 台持っており、複数のテキストエディターウィンドウを並べて表示できるので、80 列に固執しています。「6x13」フォント (trad.xterm フォント) を使用すると、80 列で 480 ピクセルとスクロールバーが必要になります。これにより、1600x1200 モニターでこのタイプのウィンドウを 3 つ持つことができます. Windows では、Lucida Console フォントはこれを行うことができません (使用可能な最小サイズは幅 7 ピクセルです)。HP LP2465などの 1920x1200 モニターでは 3 が表示されます。また、Visual Studio のさまざまなエクスプローラー、プロパティ、およびその他のウィンドウ用に、横に少し余裕があります。

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

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

「 6x13」フォントの Windows バージョンを入手できることに注意してください。

score 6 · Accepted Answer

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

public class PlaintiffServiceImpl extends RemoteServiceServlet implements PlaintiffService {

これは 94 文字の長さで、クラス名は非常に短い (GWT 標準による)。2行だと読みづらいですが、1行だととても読みやすいです。それについて実用的であり、したがって「下位互換性」を許可するため、100 文字が適切な幅だと思います。

score 6 · Accepted Answer

他の回答はすでに物事をうまくまとめていますが、コードをコピーして電子メールに貼り付けたい場合、またはコードではない場合は差分を検討することも検討する価値があります。

「最大幅」があると便利なときです。

score 5 · Accepted Answer

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

次の人は 17 インチの画面を持っているか、テキストを読むために大きなフォントが必要になるかもしれません。制限はどこかにある必要があり、以前の画面の制限により 80 文字が慣習になっています。新しい標準 (120 文字) と何か考えられますか? 「それが Xpt フォントで私のモニターに適合するものである」以外のそれを使用することをお勧めする理由は何ですか?

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

しかし、まず時間をかけて「このコードは本当に 80 文字以内に収まらないほどひどいものなのだろうか?」と考えてみてください。

score 5 · Accepted Answer

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

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

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

score 5 · Accepted Answer

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

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

score 5 · Accepted Answer

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

score 4 · Accepted Answer

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

80歳にとどまらない理由は、

識別子の意味を持つ長い名前を好む
C の構造体と列挙型の typedef を気にしないでください (それらは悪いものであり、有用な情報を非表示にします! 信じられない場合は、「Deep C Secrets」の Peter van der Linden に尋ねてください)、struct FOO func(struct BAR *aWhatever, ...)コードには typedef 狂信者のコード以上のものがあります。 .

そして、これらのルールの下では、わずか 80 文字/行で、私の目で許容できると思われるよりも頻繁に醜い改行が発生します (主にプロトタイプと関数定義で)。

score 4 · Accepted Answer

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

score 4 · Accepted Answer

他の方もおっしゃっているように、(1)印刷、(2)複数ファイルを縦に並べて表示するのに最適だと思います。

score 3 · Accepted Answer

これにはすでに多くの適切な回答がありますが、IDE では、左側にファイルのリストがあり、右側に関数のリスト (またはその他の構成) がある可能性があることに言及する価値があります。

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

score 3 · Accepted Answer

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

私は真剣です。通常、読みやすさや印刷のしやすさを犠牲にすることなく、1 行に 100 ～ 120 文字と同等のものを取得できます。実際、適切なフォント (Verdana など) と構文の色分けを使用すると、さらに読みやすくなります。数日間は少し奇妙に見えますが、すぐに慣れます。

score 2 · Accepted Answer

私は一日中並べて比較していますが、おかしな 22 インチのモニターは持っていません。私がそうするかどうかはわかりません。もちろん、これは、アローコーディングと 300 文字の行を楽しんでいる書き込み専用のプログラマーにはほとんど関心がありません。

score 2 · Accepted Answer

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

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

しかし、それは長い時間からの食でひどく見逃されています! (実際には 2003 年以降)、主にテキストエディターのワードラップには以下が含まれるためです。

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

score 2 · Accepted Answer

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

私は主に Python コーダーなので、これにより 2 つの制限が生じます。

長いコード行を書かない
インデントしすぎない

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

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

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

score 1 · Accepted Answer

はい、この時代でも、ディスプレイに 80 文字しか表示できない端末 (主に端末エミュレータ) でコーディングしている人がいます。したがって、少なくとも私が行っているコーディングでは、80 文字のルールに本当に感謝しています。

score 1 · Accepted Answer

私は実際に自分のコードでも同様のルールに従いますが、コードを A4 ページに印刷するという理由だけで、目的のフォントサイズには 80 列が適切な幅です。

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

制限の背後にある理由を疑問に思わないでください-真剣に、誰もそれがそうである正当な理由を思いつくことができない場合、コーディング標準からそれを削除する良いケースがあります.

score 0 · Accepted Answer

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

score 0 · Accepted Answer

コードを印刷してマークアップできるように、生徒に80列に絞るように強制します。

そして、約17年前、私は自分のコードを88列に拡張しました。これは、Nowebを使用してすべてを開始し、TeXを使用してきれいに印刷されたドキュメントに88列が収まるためです。

2つのスペースだけでインデントしますが、余分な部屋は素晴らしいです。

score 0 · Accepted Answer

これらのいずれかがあれば、この議論はありません！;-)

しかし、真剣に人々が彼らの答えで提起した問題は非常に正当です。ただし、元のポスターは制限に反対しているわけではなく、80列が少なすぎるだけです。

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

印刷に関しては、通常、100文字の行が印刷されたページに非常に快適に収まることがわかります。

score 0 · Accepted Answer

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

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

score 0 · Accepted Answer

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

(これは少し OT かもしれませんが、Eclipse には、保存時にコードをフォーマットするオプションがあります (任意の規則に従って)。これは最初は少しおかしなことですが、しばらくすると、生成されたコードがそうであるように、書式設定はあなたの手の中にありません。)

score 0 · Accepted Answer

私たちは最近調査を行いました。ほとんどの人がgnome ターミナル内でvimを使用します。垂直分割を行うと、標準のフォントサイズと画面解像度 1280x1024 で列数が 78 になります。

そのため、列数が (約) 75 文字のコーディング標準に全員が同意しました。大丈夫です。

text-editor - 現在、コード ファイルの最大幅を 80 文字にする正当な理由はありますか?

32 に答える 32

Related

Reference

text-editor - 現在、コードファイルの最大幅を 80 文字にする正当な理由はありますか?