このようなドキュメントの作成で発生する問題の1つは、ソーステキストの右境界線です。 以前は、80（または76）文字の右境界線を使用するのが慣習でした。 しかし、今ではモニターは広くなっています。 たぶんあなたはそれを制限することはできませんか？ または、とにかく制限する必要がありますか？ ここで、たとえば、最近ではこの記事で、この問題が非常に多くの論争を引き起こしています。 カットの下で、この質問に対する私のビジョン+投票。
なぜ80文字という制限があるのですか？ 少し歴史。 もちろん、テキストモードの古いモニターにはこのような幅があったことをすぐに思い出します。 この制限は、モニター（ビデオシステムと共に）にグラフィックモードがまだない場合に特に重要でした。 そのため、プログラムテキストを80文字、さらには78文字、さらには76文字に収めることが決定されました。 あまり高品質ではないモニターでは、右側と左側がひどくゆがんだり、ケースの後ろに隠れていたりしたため、80未満が一般的でした。 私は多くのモニターに出くわしましたが、左右で慣れ親しんでいたものの約半分を失いました。
モニターに加えて、プリンターにはこの幅がありました。 もちろん、幅広いプリンターもありました。 しかし、A4用紙または同じ（210mm）幅のロール用に設計された最も手頃なプリンターは、用紙に同じ80文字をきれいに印刷しました。
さらに、パンチされたカードには80文字も含まれていました。
つまり、80文字の行幅は、事実上、IBMによって導入された業界標準でした。
ストーリーを整理しました。
まあ、神はパンチカードとプリンターで彼らを祝福します。 個人的には、ゼロの最初から、ソーステキストを紙に印刷する必要はあまりなく、パフォーマンスカードは完全に過去に消えました。
問題が発生する可能性があります：ソーステキストが海外に送られるという事実の問題は何ですか？ たぶんそれをさせて？ コンパイラは、文字列の長さを実際に気にしません。 また、画面の幅が80文字のままで、画面の右端の背後にあるものをIDEで調べる必要がある場合でも、カーソルをこの行に移動して最後に移動できます。 たぶんこれは出口ですか？
そうでもない。 これはオプションではありません。 コンパイラだけでなく、読むためのソーステキストを作成します:)。 ソースコードを読むプログラマが一目で何かを一度に見ないと、高い確率で何かを見逃して理解できなくなります。 または時間をかけてください。
しかし、なぜ現代のモニターではこの標準から逃れられないのでしょうか？ 実際、80文字の重要性は、比較的高解像度のグラフィック画面に移行するにつれて低下し始めました。 640x480 VGAアダプターの解像度で、画面に同じ80文字（各文字の幅ごとに8ピクセル）を超える文字を収めるのが困難でした（ただし、文字ごとに5および6ピクセルの幅の比較的読みやすいフォントを見ました）。 1024x768の解像度でさえ、レンダリング文字の品質を改善するか、1行あたりの文字数を増やすことができました。 または、ソーステキストの左右にいくつかの追加機能（プロジェクトツリー、他の開発者とのチャットなど）を追加するだけです。
別のオプションがあります -文字列を自分でラップしないでください。ただし、自動的に表示されたときにこの作業をIDEに残します。 つまり、実際にはこれは1つの長い行ですが、IDEではハイフンで表示されます。 たぶんこれは出口ですか？ 原則として、これはすでにそれほど悪くはありません...何らかの理由で、このオプションはiOS開発者にとって馴染みのあるものであることが判明しました。 おそらく、Objective-C言語のコレクションに関連して、別の行への折り返しが常に明らかであるとは限らないためです。 つまり、どこに何を正確かつ正確に転送するかが常に明確とは限りません。 それがおそらく、AppleがIDEでデフォルトで（Xcodeと呼ばれる）このオプションをデフォルトで有効にした理由です。
しかし、再び。 私たちは人々のためにソーステキストを書いています。 そう？ また、このような自動転送モードでは、関数の構造が失われる可能性があるため、ロジックを理解するのが難しくなります。 したがって、これも悪いオプションです。
3番目のオプション 。 近代的な1920年代とそれ以上の幅のピクセルでは、多数の文字を表示することは問題ではありません。 正しい境界線をそのまま残すこともできますが、同時に古い80から160に増やしますか？ または少なくとも120文字？
まあ、このオプションは前のものよりも優れています。 そしてまだ。 もちろん、モニターの幅は広くなりました。 アスペクト比が9:16または10x16で、ワイド側、たとえば1920ピクセルまたは2560ピクセルのテキストの解像度を使用すると、多くの容量に対応できます。 さらに、高品質のフォントレンダリングを備えています。
そして、すべてがうまくいくでしょう...さて、ソーステキストのいくつかのブランチを結合（フリーズ）する必要がある場合は？ たとえば、3ポイントマージはどのようになりますか？
たとえば、以下は KDiff3のスクリーンショットです 。 特にこれは：
モニター上でソース文字のコピーが120文字、幅が合計1920ピクセルの3つのコピーのようになります。 フォントレンダリングの品質を犠牲にする必要があります。つまり、サイズを小さくして目を痛めます。 または、右の境界線の後ろに隠れているロジックの一部を失います。 通常、2番目のオプションは受け入れられません。 競合の結果、3ポイントマージの必要性が生じたためです。 そして、私（またはあなた）にとって、マージプロセスでは、別の開発者がベース（中央）に関連するソーステキストの左バージョンとベースに関連するソーステキストの右バージョンに実装したロジックを正確に理解する必要があります。 すべてのロジックを確認する必要があります！
画面幅が1920ピクセルの場合、ソーステキストの3つのバージョンすべての幅が1文字につき8ピクセルで80文字になります。 そして、それは行番号、境界線などを表示するオーバーヘッドをカウントしていません。
したがって、私は76文字で海外にいます！
さて、3ポイントmerzhは毎日発生しません。 境界線を100文字にします。 しかし、もうありません:)