ワイドスクリーンモニターでは、スクロールバーなしで一度に80文字以上を簡単に見ることができます。linus torvaldsでさえ80文字という制限は時代遅れだと考えています。
だから、ワイドスクリーンモニターの時代には80文字の制限がまだ関連していますか?
ワイドスクリーンモニターでは、スクロールバーなしで一度に80文字以上を簡単に見ることができます。linus torvaldsでさえ80文字という制限は時代遅れだと考えています。
だから、ワイドスクリーンモニターの時代には80文字の制限がまだ関連していますか?
回答:
まだ80文字の制限を厳守するいくつかの理由があります(または、74文字の制限がさらに優れています。コードレビューを行うと、差分マーカーと電子メールの引用が追加された場合でも、コードを80列未満に抑えることができますメーリングリスト)。
ワイドスクリーンモニターの時代でも、複数のウィンドウを並べて開いて、コードのさまざまな部分を表示するのが好きです。たとえば、通常、1つの画面でWebブラウザーと電子メールを開き、2番目のモニターで2つのファイルと端末を並べて開きます。80列を超える行がある場合は、行を折り返すエディターを処理する必要があります(これはいため、コードの移動が難しくなります)。または、画面に多くの行が収まらないようにウィンドウを広げます。一度。
通常この方法で編集しなくても、横並びのdiffツールを使用する場合、差分を表示しやすくする適切な行長のファイルに感謝します。
コード密度の問題もあります。コードを読むとき、私は多くのコンテキストが好きです。ウィンドウを上下に見るのは、スクロールするよりもはるかに高速です。非常に長い行がある場合、行の長さが大きく異なる傾向があり、多くの無駄な画面領域をもたらし、特定の時間に画面に収まるコードを減らすことができます。
最後に、非常に長い行がある場合、それは一般に、非常に複雑な行、深い意志、または非常に長い識別子があることを意味します。これらはすべて問題になる可能性があります。複雑な線はおそらく多すぎます。それをいくつかのより単純な行に分解できる場合は、おそらくそうすべきです。深いインデントは、おそらくあまりにも多くのループと条件式をネストしていることを意味し、コードフローを混乱させる可能性があります。いくつかの機能へのリファクタリングを検討しています。また、識別子が長すぎると、コードの読み取りが非常に困難になる可能性があります。人々は通常、単語を個々の単位として認識します。すべての文字を1つずつ読むのではなく、単語の全体的な形を見ていきます。長い識別子は、この方法で区別するのが難しく、通常、長い識別子の場合、冗長または反復的な情報が含まれます。
現在、コードを80列未満に保つことは依然として良い習慣ですが、これは宗教的に従う必要のある規則の1つではありません。すべてのコードを80列未満に抑えることをお勧めしますが、収まらない場合でも、あまり心配しないでください。
std::vector<...>::const_iterator
後者の場合、通常はtypedefによって状況を緩和できます)。
行を約100文字未満に保つと、ワイドスクリーンモニターに2つのエディターウィンドウを並べて表示できます。クラスヘッダーファイルと実装の両方を同時に表示したり、一方のコードをもう一方のコードに呼び出したりすることは非常に便利です。また、行を短くしておけば、エディターウィンドウに水平スクロールバーは必要ありません。これにより、垂直方向のスペースが増えます。
80文字は時代遅れかもしれませんが、物事を理にかなった状態に保つにはいくつかのメリットがあります。
私はモニターがそれと何か関係があるとは思わない-少なくとももう。
80文字で行をコーディングできない場合、それはおそらく悪いコードの兆候です。複雑な式。深すぎるインデント。など。あなたがやっていることをやめて、考え直すべきです。
ただし、コードに80行以上必要であることが確実な場合は、先に進んでください。慣用的な変更を追加して小さくするよりも、80文字を超えるコードを使用する方が良いと思います。
私は個人的にこの種のものが嫌いです:
ret = my_function(parameter1, \
parameter2, \
parameter3, parameter4);
単純ではなく:
ret = my_function(parameter1, parameter2, parameter3, parameter4);
80文字の制限を正確に選択することはおそらく関係ありません。たとえば、制限が85の場合、何が変わりますか?
今日使用されているモニターの解像度が高いのは事実ですが、テキストエディター/ IDEでは、すべてのスペースがテキストビューから取得されるわけではありません。私が使用するエディターでは、プロジェクトに含まれるファイルのリストが左側に表示されます。
ネットブックまたはノートブックで使用される解像度は、モニターで使用される解像度とは異なります。誰にも「問題」を引き起こさない文字数制限を使用することはおそらく理にかなっています。
本当に開発環境に依存します。
たとえば、数千人の開発者がいる大企業では、おそらく製品のライフタイムの間にコードの一部を見なければならない人が何百人もいます。多くの人がいるので、何らかの理由(古いハードウェア、ネットブックなど)で800x600以下で動作している人は少なくありません。それらに対応することにはいくつかの価値があります。
私の25人の会社で、しかし、私はそれをねじ込むと言います。私たちは皆、最大解像度でデュアルモダンモニターを使用しています。120-140程度が非公式のガイドラインです。
ある程度の制限があることは確かに理にかなっています。ただし、80文字の制限は制約が厳しすぎます。私は96文字の制限のようなものを好む。私が対処しなければならないコードのほとんどに十分な幅であり、(ワイドスクリーンで)diffのために2つのファイルを並べて配置できるように十分に狭いです。
コードの可読性は他のすべての懸念事項に勝ると信じています。また、行コードあたり96文字を使用すると、80文字よりもはるかに読みやすくなります。
私は、ほとんどの人が端末を80文字幅に設定し、プリンタが80文字より長い行を折り返さなければならないという議論を買いません。かつては(遠い)過去にあったので、厳しい制限ではありません。端末とプリンターの幅を100文字に簡単に設定できます。
いいえ、関係ありません:
80文字は、コンソール環境での固定幅フォントのガイドラインでした。
もちろん、コンソール環境で固定幅フォントをまだ使用している場合は...確かに、80文字が賢明です:)