コメントの水平線

Question

これは主に個人的な好みに左右されることを認識していますが、以下に明らかな欠点があるかどうかは不思議です。

私は同じファイル内で、ソースコードを論理的なグループに（コメントで）分けています。

---

//---------------------------------------------------------------------------- 
#include "..." 
//---------------------------------------------------------------------------- 
#include <...> 
//---------------------------------------------------------------------------- 
#include <boost/...> 
//---------------------------------------------------------------------------- 
#include <os-specific/...> 
//---------------------------------------------------------------------------- 
namespace 
{ 
    void Foo() 
    { 
    } 
} 
//---------------------------------------------------------------------------- 
namespace 
{ 
    void Bar() 
    { 
    } 
} 
//---------------------------------------------------------------------------- 
namespace 
{ 
    void Baz() 
    { 
    } 
} 
//---------------------------------------------------------------------------- 
int main() 
{ 
} 
//---------------------------------------------------------------------------- 
//This file ends with a new-line. 

または：：たとえば

//---------------------------------------------------------------------------- 
#ifndef FOO_HEADER_INCLUDED 
#define FOO_HEADER_INCLUDED 
//---------------------------------------------------------------------------- 
#include "..." 
//---------------------------------------------------------------------------- 
namespace Foo 
{ 
    void Bar(); 
} 
//---------------------------------------------------------------------------- 
#endif 
//---------------------------------------------------------------------------- 
//This file ends with a new-line. 

---

私は最近、いくつかの外国人のソースを読んされていると私は、事実上誰がこれを行わないことに気付きました。

この種の「除算」に対して私が思いつく唯一の議論は、あなたの除数（~80文字よりも長い場合）が改行されるポートレートモードでソースコードを物理的に印刷する場合です。しかし、これはランドスケープモードでは問題になりません。

正直言って、なぜ私がこれをやり始めたのか分かりません。このOCDの賛否両論は他にもありますか？

さらに、私の場合、この種の動作は言語に依存しません。先日シェルスクリプトを書いていて、まったく同じ動作パターンに気づいた。

Answer 1

私はこれまでずっとずっと何かをしていました。私は、インクルード、宣言、関数などのブロックのセクション見出しを持っています。

私はそれをやって終了し、いくつかの理由があります：

1. は、それは維持するために、もう一つのことです。新しいコードを書くときにそれらを追加して、削除したときにそれらを取り出すことを覚えておく必要があります。私はむしろ、コード自体に精神的な努力を費やし、休憩を保証するのに十分なものがあるかどうかに執着しないでください。

2. 分類が容易なものもあります。ある関数の中に小さなクラスを入れたいとします。あなたは本当にそのような行を関数の途中に追加しようとしていますか？

3. スマートエディタを使用すると、コード内を移動しやすくなりました。もともとは、ファイルを上下にスクロールして物を見つけたときに、すばらしいランドマークでした。しかし、Emacsでは、インクリメンタルな検索とタグファイルを使って多くのことを飛び越しています。また、IDEを使用する場合は、サイドにあるファイルの部分を表示し、クリックしてそのファイルにジャンプさせてください。

4. 私がうまくいくにつれて、私は小さくなったモノリシックなモジュールに移行しました。最近は、既存のソースファイルに新しいセクションを追加するのではなく、新しいファイルに移動するだけです。ファイル自体が論理グループを提供します。各ファイルは緊密でまとまった単位です - なぜそれを分解してください？

5. Javadoc/Doxygenスタイルのコメントを一貫して使用しました。これらは、ランダムな水平線よりも説明的であり、コード内で見た目が非常によく見えることもわかりました。 Cソースファイルで

Answer 2

いいIDEを使用していないように見えます。 たとえば、VSで#regionsを使用してコードをグループ化することができます。あなたの方法よりはるかに簡単です。

Answer 3

私たちの中には、あなたと同じくらい親切ではないかもしれませんが、私たちの中にはそれらを使っているものもあります。私の答えはthis questionです。

Answer 4

リージョンはコードを分割する方がはるかに良い方法です。私は現在、「flowerboxing」（I.E。/ *****と****/commentsで囲んでいるもの）に対するポリシーを持っていますが、私はそれが水平バーにも当てはまると確信しています。

私は地域にこだわっていて、物事をはるかに良く見えるようにします。

Answer 5

、私などの#define、型定義、静的（ファイルスコープ）変数の定義および関数プロトタイプ、パブリック関数と静的関数としてのセクションにファイルを分割テンプレートを持っています（同様にCヘッダファイルも）。これらは '='の行で区切られています。

上記の質問とは異なり、これらは既存のコードブロックをグループ化するために作成されません。 I は、各ファイルに便利な構造を提供し、作成しているコードをどこに置くかを指示します。

また、各機能の間に ' - 'の行があり、必要に応じて他のセクションの論理グループ間にあることもあります。

他に何もない場合は、ファイルをスクロールするときに関数の開始位置と終了位置を確認できると便利です。