Java用の "ラインルール"のコーディング規約があります

Question

私はJavaファイルを少し整理したいと思いますが、これを行う標準的な方法があるかどうかを知りたいと思います。たとえば：

public class Example 
{ 
    private int exampleInt; 
    private String exampleString; 

    /*------------------------------------------------------------*/ 
    /* I N N E R C L A S S E S         */ 
    /*------------------------------------------------------------*/ 
    private someInnerClass 
    { 
      someInnerClass() 
      { 
      } 
    } 
    /*------------------------------------------------------------*/ 

    /** 
    * This method returns the example int. 
    */ 
    public int getExampleInt() { 
      return exampleInt; 
    } 
} 

私は私がコメントブレーク /のようなものを持っている部分が--------------------呼び出すことはありません---------------------------------------------/ ありますか？この種のもののためのどんな種類の大会ですか？または、ほとんどのIDEが何らかのアウトラインビューでうまくすべてを表示するので、私がやってはいけないことですか？

Answer 1

リファクタリングとソースのクリーンアップにより、コメントを含むソースファイルが再編成されることがあります。

私はあなたがそうしないことをお勧めします。そのコメントは全く関係のないどこかで終わるかもしれないからです。

IDEを使用してソースを再フォーマットすることをお勧めします。 Eclipseでは、ファイルを保存するたびにそれを実行できます。これにより、すべてのコードに一貫性のある外観が与えられ、読みやすくなります。

Answer 2

コード自体について説明します。これらの醜い長いコメント行を置く必要はありませんあなたは本当に、そのようにように、それらを短くする必要がある場合：。

// ------------- 
// Inner Classes 
// ------------- 

これはそれほど厄介です。私がこの種のコメントを見つけたとき、明らかにそういうコメントが出てきたら、通常はすぐに削除します。

Answer 3

あなたはJavadocツール用のコメント規則を見てみる必要があり、NetBeansと他のIDEのは、あなたのコードがどのように動作するかの主説明としてそれらを取るために使用され、それが問題

How to Write Doc Comments for the Javadoc tool

なしでそれを概説する必要があります

Answer 4

あなたのチームの誰かがあなたのコメントブレークコンベンションに従わないことを望むなら、どんなところでも彼らのメソッドを置くことを止めるのはどうでしょうか？彼らが方法を誤ってしまったら、どうやってそれを見つけますか？コメントのブレークはコンプライアンスを強制するものではないので、あなたはそれらを信用できません。だから、IDEの優れた機能を使ってメソッドを見つけようとしたら、最初からやってみませんか？

要約すると、そうすることができますが、それはあなたのコードを分ける信頼できる方法ではありません。

Answer 5

これらの行コメントを削除することをお勧めします。彼らは物事を乱すだけです。空白は視覚的にコードのブロックを設定し、ソースの混乱を招かないため、さらに効果的なIMOです。

Answer 6

私はあなたの例のもののようなコメントを目が痛いと感じる傾向があります。十分な内部クラスをグループ化している場合。余分なノイズが発生する理由はありません。さらに、優れたIDE（Eclipse、IntelliJなど）は、コードの構造要素を一覧表示、フィルタリング、グループ化します。

Answer 7

あなたの質問に答えるために、私はそのような慣習があるとは思わない。

太陽のCode Conventions for Javaは、このようなことは絶対に言及しません。

私のお勧めはです。です。私のプロジェクトでは、タイプレベルで適切にフォーマットされたJavaDocコメントと、主要なAPIメソッド（主にインターフェース上のパブリックメソッド）のメソッドレベルJavaDocと、特定の実装が文書化に値するほど特別な場合の具体的なメソッドを提供します。

私はジュニア開発者（自分自身も含めて）が好きなことだと思っていますが、実際にはそれほど価値がないという負担です。

Answer 8

私はセクション区切り記号のための普遍的に受け入れられている慣習は知らない。 （私はそのような人の一人になります）、他の人はそれらが不必要な気晴らしであると感じます。どちらのグループも正しかったり間違ったりすることはありません。それは残念ながら、いくつかの開発者にとって宗教上の問題に近づくことができる個人的な好みの問題です（エディタの選択、言語の選択などとは異なります）。

私は重要なのは、特にプロジェクト全体の標準がない場合、他の開発者との一貫性と敬意を表することだと思います。特定のファイルの主なメンテナーではなく、そこで変更を加える必要がある場合は、すでにフォーマットされているフォーマットに従うことをお勧めします。

Answer 9

コードを明確にし、不要なコメントを削除します。コードは、それ自体が何をしているのか、APIの一部であるコンストラクタ&のメソッドを文書化し、明確かつ簡潔にする必要があります。