スタイル：JavaScriptでの行の長さとコメントの折り返し

Question

私はコードのために1行あたり80文字未満で問題ありません（たとえ 一部の制限が古いことを考慮 ）場合でも、分割commentsを複数行で記述し、1行に（必要な限り）記述して、編集者に折り返しを処理させる。

コメントは、テキストではなく（コードではなく）性質があり、読みやすさを考慮し、パラグラフ（行ではなく）の向きを考えると、個別のディスカッションに値すると思います。

コメントスタイル に関する説明を読んだ後、重要な開発フローの側面を次のように絞り込みました。

• ラッピングをサポートしていないエディターを使用することは問題でも言い訳でもありません。私はコードの主要なメンテナーであり、GitHubを介して非常にまれに貢献しています。 emacsまたはviは使用されません。
• GitHubで公開されているコードは、ソフトラップをサポートするエディターでの編集を容易にするはずです。
• 私はスタイルを選ぶことができるので、既存のスタイルに固執することはありません。

任意の線の長さ-長所

• たまたま検索した2つの連続した単語が\n *で任意に区切られていても、検索は失敗しません
• 優れた画面の不動産利用

任意の線の長さ-短所

• ソフトラッピングでは、JSDocで奇妙に見えます：
• 非常にマイナーですが、GitHubの差分モードはデフォルトで「統一」されており、 水平スクロールバー が表示されます。ただし、[分割]をクリックすると、GitHubの差分ソフトラップは
• GitHubのビューアはラッピングをサポートせず、幅は128文字です（ただし、一部の "GitHubワイド" ユーザースタイルが存在します）。

限られたラインの長さのプロ：

• テキストは 50-75文字/行 で最も速く読み取られますが、ここでは小説を作成していません。コメントを読んだ場合、数秒余分に費やすことができます
• ラッピングをサポートしないレガシーツールでの表示を改善

制限された行の長さの短所：

• コメントの各行をハードラップしながらコメントの先頭にテキストを挿入すると、誤った差分のカスケードが簡単に発生する可能性があります。

実際には、上記のdiffの問題がかなり一般的で耳障りなものであるにもかかわらず、ほとんどの場合ハードラップ（行の長さが制限されています）を見てきました。

私には何が欠けていますか、そしてどのようにして決定できますか？

現代のプロジェクトでは、恣意的に長い行が一般的に見られないのはなぜですか？

Answer 1

状況を詳細に分析したようです。yourコンテキスト要因は主にGitHubです。

他のプロジェクトでは、コンテキスト要因はIDEが使用されており、3つの状況が最も使用されています：

• 80文字の制限。これは、emacs/viを使用している開発者、または盲目的にいくつかのスタイル規則に従っている開発者にとって興味深い選択です（興味深い点は、 jslintのmaxlenデフォルト値はunlimited ）です。

  ここでの利点は一貫性です。テキストエディターの適切なプラグインも役立ちます。ユーザーが入力すると、エディターは行末を処理して80文字の制限を適用します。それと同じくらい簡単です。

  80の制限が一般的ですが、他の数値も使用できることに注意してください。これは通常問題にはなりません。場合によっては、カスタム構成が必要になることもあります。

• 制限なし。これは、IDEでワードラップの構成に力を入れた人に最適です。メアリーが24インチモニターで彼女のVisual Studioを使用していて、ジェフが19インチのラップトップで作業している場合、ジェフの実際の行あたりの文字数はメアリーよりもはるかに少ないかもしれません。ただし、Visual Studioは可能な限り正確に文字を表示し、必要に応じて新しい行に移動するため、問題ではありません。

  ここでの利点は、他の開発者が使用する実際のIDE /構成について誰も気にしないことです。テキストは誰にとってもきれいに表示され、誰もが幸せです。かつて、チームはemacsまたはviを愛する開発者を雇うまで、そしてワードラップを処理できないツールの使用を開始するまで、.

• 「これは私のマシンで機能します」という制限があります。ウィンドウのサイズを変更できるIDEを使用し、ワードラップを設定していない開発者は、見栄えの良い場所に改行を挿入する傾向があります。彼らは173文字のウィンドウにテキストを入力し、文字171に達すると改行して新しいWordを新しい行で開始します。

  これは間違ったアプローチです。

  1. このようなテキストは、ウィンドウのサイズが変更されるとすぐに見苦しくなります。 168文字にすると、垂直スクロール（ewwww！）または次のようなワードラップが表示されます。

     //                                       The arbitrary line end is here ↴
     //                                        The new Word-wrap is here ↴   ┊
     ····if·(this.windowActive·&&·this.findStartupTimer().isExpired)↵    ┊   ┊
     ····{↵                                                              ┊   ┊
     ········console.log('Entering·the·primary·loop.');↵                 ┊   ┊
     ········//·TODO:·implement·the·primary·loop·which·will·handle·the·▖ ┊   ┊
     events↵                                                             ┊   ┊
     ········//·from·the·application.↵                                   ┊   ┊
     ····}↵                                                              ┊   ┊
     

     ^{開発者は、「イベント」の後に改行を挿入して、テキストを元の行末のコンテキストで見栄えよくすることを決定しました。ウィンドウの幅が少し狭くなるとすぐに、ワードラップが可能なIDEは、「handle the」の後に新しい行を導入し、「events」が行に単独で表示されるようにします。これは特に読みやすくありません。}

     大きな画面にも対応していません。全員が一貫した制限を使用した場合、それは耐えられます。右側のスペースを無駄にしますが、softwareengineering.SEのこのページでは、モニターのスペースの3分の2が単に空白になっています。ただし、問題は一貫性の欠如です。これは、このサイトの質問が幅1000ピクセルを使用し、回答が幅800ピクセルを優先し、コメントが1200ピクセルに及ぶようなものです。

  2. 「こんにちは、ここで改行するといいですね」というルールに対応できるツールはほとんどありません。コミット時に自動的に強制することはできません。 IDEに改行を挿入するように依頼することはできません。

残念ながら、一部のコミュニティでは、「これは私のマシンで機能します」という制限が非常に人気があります。 Visual Studioが既定でワードラップを無効にするという誤った決定を下し、ほとんどのプログラマーがそれを有効にする方法を知らないため、企業のC＃コードはこれらの厄介な改行でいっぱいです。それらの1つではありません。

厳密で一貫した制限と制限なしのどちらかを選択する場合は、使用するツールに応じて選択してください。あなたの場合、選択は制限の欠如であるようです。