ワイドスクリーンモニターの時代には、80文字の制限がまだ関係していますか?[閉まっている]


56

ワイドスクリーンモニターでは、スクロールバーなしで一度に80文字以上を簡単に見ることができます。linus torvaldsでさえ80文字という制限は時代遅れだと考えています。

だから、ワイドスクリーンモニターの時代には80文字の制限がまだ関連していますか?


1
たとえば、Eclipseで行を短くすることには、非常に良い理由があります。これにより、行を折り返さずに、通常のプリンターで読み取り可能なフォントでプログラムを印刷できます。

どのような文脈で?特定のプログラミングコンテキストで質問する場合は、再開することに投票します。
ニコール


Visual Studioのワードラップは壊れているため、ほとんどのユーザーはこれを無効にします。代わりに、手で改行を入れます。これは、画面の幅が異なる人にとってはひどく見えます。visualstudio.uservoice.com/forums/121579-visual-studio/...
大佐はパニック

回答:


28

まだ80文字の制限を厳守するいくつかの理由があります(または、74文字の制限がさらに優れています。コードレビューを行うと、差分マーカーと電子メールの引用が追加された場合でも、コードを80列未満に抑えることができますメーリングリスト)。

ワイドスクリーンモニターの時代でも、複数のウィンドウを並べて開いて、コードのさまざまな部分を表示するのが好きです。たとえば、通常、1つの画面でWebブラウザーと電子メールを開き、2番目のモニターで2つのファイルと端末を並べて開きます。80列を超える行がある場合は、行を折り返すエディターを処理する必要があります(これはいため、コードの移動が難しくなります)。または、画面に多くの行が収まらないようにウィンドウを広げます。一度。

通常この方法で編集しなくても、横並びのdiffツールを使用する場合、差分を表示しやすくする適切な行長のファイルに感謝します。

コード密度の問題もあります。コードを読むとき、私は多くのコンテキストが好きです。ウィンドウを上下に見るのは、スクロールするよりもはるかに高速です。非常に長い行がある場合、行の長さが大きく異なる傾向があり、多くの無駄な画面領域をもたらし、特定の時間に画面に収まるコードを減らすことができます。

最後に、非常に長い行がある場合、それは一般に、非常に複雑な行、深い意志、または非常に長い識別子があることを意味します。これらはすべて問題になる可能性があります。複雑な線はおそらく多すぎます。それをいくつかのより単純な行に分解できる場合は、おそらくそうすべきです。深いインデントは、おそらくあまりにも多くのループと条件式をネストしていることを意味し、コードフローを混乱させる可能性があります。いくつかの機能へのリファクタリングを検討しています。また、識別子が長すぎると、コードの読み取りが非常に困難になる可能性があります。人々は通常、単語を個々の単位として認識します。すべての文字を1つずつ読むのではなく、単語の全体的な形を見ていきます。長い識別子は、この方法で区別するのが難しく、通常、長い識別子の場合、冗長または反復的な情報が含まれます。

現在、コードを80列未満に保つことは依然として良い習慣ですが、これは宗教的に従う必要のある規則の1つではありません。すべてのコードを80列未満に抑えることをお勧めしますが、収まらない場合でも、あまり心配しないでください。


3
同意した。ただし、長い識別子は(「意味のある名前を使用する」や「不可解な略語を避ける」などのコーディングガイドラインによって)必要な場合があります(std::vector<...>::const_iterator後者の場合、通常はtypedefによって状況を緩和できます)。
ムシフィル

大きな理由。あなたのチーム(またはメーリングリスト)がそれに同意する限り、正確な行の長さが重要であるかどうかはわかりません。個人的には、ボブおじさんの提案で、120文字を超えないようにしています。
アラン

1
@musiphilええ、だから最後の段落を含めました。メソッドを宣言するときに、クラス名、メソッド名、戻り値の型を80列の1行に収めることができなかったC ++の行に遭遇しました。本当に奇妙な改行をするよりも、その1行の80列(または100列)の規則を破る方が良いでしょう。
ブライアンキャンベル

46

行を約100文字未満に保つと、ワイドスクリーンモニターに2つのエディターウィンドウを並べて表示できます。クラスヘッダーファイルと実装の両方を同時に表示したり、一方のコードをもう一方のコードに呼び出したりすることは非常に便利です。また、行を短くしておけば、エディターウィンドウに水平スクロールバーは必要ありません。これにより、垂直方向のスペースが増えます。

80文字は時代遅れかもしれませんが、物事を理にかなった状態に保つにはいくつかのメリットがあります。


1
+1、私は頻繁に複数のソースファイルをVimまたは他のエディターで並べて開きます。フォントが十分に小さく、右マージンがかなり狭いため、プロジェクトの概要をすばやく把握でき、多くのドキュメントを開くことさえできます。
greyfade

4
多くの人はデフォルトで端末とエディターをその幅に設定しているため、80文字は依然として適切です。したがって、80に制限すると、すべてのウィンドウを再配置したり、行の折り返しや水平スクロールを処理したりするのではなく、それらの人々に対して友好的になります。
ブライアンキャンベル

1
80文字は依然として妥当です。それより長くすると、(リファクタリングの代わりに)ネストされたコードが促進され、多くのウィンドウが並んでいると非常に便利です。別のモニターを追加すると、一度に表示できるウィンドウの数が増えます!
ドナルドフェローズ

1
80はVMSに優しいかもしれません。私の新しい年齢の考え方を許しますが、可能な限り制限を延長し、必要な場合はそれを維持する必要があります
ロス

29

私はモニターがそれと何か関係があるとは思わない-少なくとももう。

80文字で行をコーディングできない場合、それはおそらく悪いコードの兆候です。複雑な式。深すぎるインデント。など。あなたがやっていることをやめて、考え直すべきです。

ただし、コードに80行以上必要であることが確実な場合は、先に進んでください。慣用的な変更を追加して小さくするよりも、80文字を超えるコードを使用する方が良いと思います。

私は個人的にこの種のものが嫌いです:

ret = my_function(parameter1, \
                  parameter2, \
                  parameter3, parameter4);

単純ではなく:

ret = my_function(parameter1, parameter2, parameter3, parameter4);

5
確かに、最初の例の3行目が長すぎない場合、2行目を1行目に結合できるため、見やすくなります。(かっこ内のエスケープされた改行を必要とする言語は何ですか?)

1
ああ、それは私が書いた単なる擬似コードです。しかし、Cにはそれが必要だと思います。
セザールカナッサ

4
複数行のマクロ定義でのみ、これはまれです(またはまれです)。それは最大行長の選択に大きく影響します(このようなバックスラッシュを維持するのは楽しいことではありません)。ストローマンらしい?

2
関数呼び出しで行を分割する問題が発生した場合、各パラメーターを1レベルずつインデントして、それぞれの行に配置します。
スターブルー

20

コーディングする?

確かにはい。普通の人間はあまりにも広く読むことができません。数本のコラムで目を動かさずにすれば、より集中して疲れを遅らせることができます。それは最小のゲインですが、重要なものです。


3
コードは散文とは非常に異なっていると感じていますが、定期的に(つまり、散文はより一貫性が高い)コードを120行以上に広げるコードを読むのは面倒です。

6

はい、コード行の長さを制限する理由があります。

  1. 画面は広くなっていますが、コードを印刷する必要がある場合があります。この理由だけのために
  2. Diff-viewerは、多くの場合、垂直分割で行を表示します。これは、行がワイドスクリーンで許される限り長くなると難しくなります。

とはいえ、80は少し少なすぎます。しかし、それでも、設計上の原則として、いくつかの制限はおそらく良い考えです。

時折、彼らはので、私は、余分な長い行が禁止されるべきではないと言うだろうしている必要。ただし、ほとんどの機能が30インチ画面でのみ表示可能な場合、コードにはいくつかの問題があります。


5

それはarbitrary意的ですが、読みやすいものには非任意の制限があります。テキストの超幅の列は、コードであるか散文であるかに関係なく、スキャンおよび読み取りが非常に難しいことがわかります。さらに、他の多くの答えが指摘しているように、このコードが画面に表示される唯一のものになるわけではありません。同時に2つ以上のコードウィンドウを作成し、それらを1つのワイドスクリーンモニターに収めることは素晴らしいことです。


3

80文字の制限を正確に選択することはおそらく関係ありません。たとえば、制限が85の場合、何が変わりますか?

今日使用されているモニターの解像度が高いのは事実ですが、テキストエディター/ IDEでは、すべてのスペースがテキストビューから取得されるわけではありません。私が使用するエディターでは、プロジェクトに含まれるファイルのリストが左側に表示されます。

ネットブックまたはノートブックで使用される解像度は、モニターで使用される解像度とは異なります。誰にも「問題」を引き起こさない文字数制限を使用することはおそらく理にかなっています。


5
80文字は、パンチカードの列数の厳しい制限でした!
ChrisF

5
標準が何であるかは関係ありませんが、誰もが同じ標準に従って作業すれば、生活が楽になります。
スキルドリック

2

本当に開発環境に依存します。

たとえば、数千人の開発者がいる大企業では、おそらく製品のライフタイムの間にコードの一部を見なければならない人が何百人もいます。多くの人がいるので、何らかの理由(古いハードウェア、ネットブックなど)で800x600以下で動作している人は少なくありません。それらに対応することにはいくつかの価値があります。

私の25人の会社で、しかし、私はそれをねじ込むと言います。私たちは皆、最大解像度でデュアルモダンモニターを使用しています。120-140程度が非公式のガイドラインです。


2

ある程度の制限があることは確かに理にかなっています。ただし、80文字の制限は制約が厳しすぎます。私は96文字の制限のようなものを好む。私が対処しなければならないコードのほとんどに十分な幅であり、(ワイドスクリーンで)diffのために2つのファイルを並べて配置できるように十分に狭いです。

コードの可読性は他のすべての懸念事項に勝ると信じています。また、行コードあたり96文字を使用すると、80文字よりもはるかに読みやすくなります。

私は、ほとんどの人が端末を80文字幅に設定し、プリンタが80文字より長い行を折り返さなければならないという議論を買いません。かつては(遠い)過去にあったので、厳しい制限ではありません。端末とプリンターの幅を100文字に簡単に設定できます。


1

いいえ、関係ありません:

  • とにかく、アプリケーションやWebで使用されるほとんどのフォントは固定幅ではありません。つまり、80文字!= 80文字です。
  • あなたが言ったように、画面の幅が変更されました-80文字は賢明な境界ではありません。

80文字は、コンソール環境での固定幅フォントのガイドラインでした。

もちろん、コンソール環境で固定幅フォントをまだ使用している場合は...確かに、80文字が賢明です:)


3
私は、彼がソースコードで80文字の制限を使用していることを言及していたと確信しています。
フィッシュトースター

1
うーん...その場合は...まだありませんが、他の理由で:)
ダモビサ

1
80文字は、パンチカードの列数の厳しい制限でした!
ChrisF

0

GUIでエディターを使用する場合、ほとんどの適切なエディター(たとえばNotepad ++)には行の折り返しを切り替えるボタンがあるため、1行あたり80文字は無関係です。これにより、薄いウィンドウでコードを表示する場合でも問題になりません。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.