各企業にはコード設計のための独自の標準があり、それに従うことが重要です。 IDEに組み込まれているコードフォーマッタは、基本的にコードの単純なアライメントしか許可しないため、この問題を部分的に解決します。 これに加えて、フィールド、メソッド、ネストされたクラスの両方の宣言シーケンスの順序も必要です。 標準コードが尊重されない理由は次のとおりです。プログラマーは、コードをリポジトリに送信する前に標準からの逸脱に気付かない場合があります。 新しい開発者はドキュメントを十分に注意深く読みませんでした。 ホットフィックスを追求して、彼らはフォーマットを忘れていました。 プログラマーの平凡な疲労または怠のため。 自動リファクタリングなど。 通常のレビューコードでは、時間がかかりすぎて開発が遅くなるため、問題を解決できません。作成時にコードコンプライアンスの検証を自動化する必要があります。
一般的な問題：
- コンストラクターがクラスの中央に予期せず表示されます。
- 内部クラスは、外部クラスの途中で宣言されます。
- 抽象メソッドは、大きな抽象クラスの途中で宣言されます。
- @Autowiredメソッドもどこにでも配置されますが、目立つ場所にはありません。
- 静的ビルダーメソッドはクラスコードに散らばっています。
- クラスフィールドは、内部クラスとメソッドの間のどこかで失われました。
コードでこれに耐えるのにうんざりしていませんか？
おそらく多くの人は、 Javaスタイルがユーザーによって定義された標準と一致するかどうかを自動的にチェックできるCheckStyleプログラミングスタイルチェックシステムと、EclipseプラグインEclipse-csに既に精通しているでしょう。 CheckStyleはコンソールベースで使用され、多くのプラグインとそれに基づいた検証ツールを実装しており、それが基礎となった理由です。 上記のチェックは、 宣言オーダーモジュールで部分的にすでに実装されています。このモジュールは、サンが発表した標準に従って動作します。 しかし、ニーズや独自のスタイルに合わせて標準をカスタマイズする方法はありません。 私たちの開発チームは、クラス構造の記述の設定の柔軟性により、誰もが満足する新しいテストモジュールを提案し、実装しました。
ユーザーは、フィールド（フィールド）、メソッド（メソッド）、コンストラクター（Ctor）、内部クラス（InnerClass）の正規表現を使用して、クラスのコンテンツ（構造）の目的の形式を説明するように求められます。クラス要素間の区切りは「###」です。
正規表現でクラス構造を定義する場合、アクセス修飾子、注釈、タイプ、名前を指定できます。
使用例
単純なルールの例：最初のフィールドはクラスで宣言され、次にメソッド、次に内部クラスが宣言されます：
Field(.*) ### Method(.*) ### InnerClass(.*)
フィールドの例：public statics、protected、annotation @ Autowired、private fields：
Field(public static final.*) ###
Field((private|protected) static final.*) ###
Field(@Autowired.* public) ###
Field(private.*)
「。*」テンプレートは、ルールの最後で省略できます-自動的に置換されます。
テストモジュールの結果は、ファイルを保存した直後に表示されるため、開発者は注文の違反に関する情報を即座に受け取ることができます。 Eclipseの[アウトライン]ウィンドウでは、クラスのメソッドとフィールドがマウスでドラッグされ、必要な順序が簡単に復元されるため、これを解決するのに1分もかかりません。 間違った場所にある各アナウンスは、メッセージで強調表示されます。
現実のルールの例（コードの形式）：
Field(private static final long serialVersionUID) ### Field((private|protected) final Log ([\w]*L|l)og|private static final Log [\w]*LOG) ### Field(public static final) ### Field((private|protected) static final) ### Field(@Autowired.* public) ### Field(public.*) ### Field(public) ### Field(private final) ### Field(private.*) ### Field(private) ### Field(.*) ### Method(public static void main.*) ### Method((public|protected)?\w*abstract) ### Method(public static .*(new|edit|create|open|clone).*) ### Ctor(public) ### Ctor(private) ### Method(@Autowired.* public) ### Method(.*) ### InnerClass(.*)
サポートが必要
残念ながら、このモジュールはCheckStyle 5.2および5.3リリースには含まれていません。 プロジェクトの開発者との交渉が行われ、彼はこの決定が好きではなかったものの説明を与えませんでした。 新しいチェックに関するパッチディスカッションへのリンクはこちら 。
SourceForge WebサイトのコメントでCustomDeclarationOrderCheckをサポートするようコミュニティに依頼するか、Habrahabrのコメントで拒否の考えられる理由と、それが完成する価値があるものを書いて、オープンプロジェクトでの開発を促進した経験を共有したいと思います。
モジュールの機能を確認したい人は、アセンブリを使用できます。
これを行うには、ご使用のバージョンのEclipse-cs（ 更新サイト ）のアーカイブをダウンロードし、アーカイブからnet.sf.eclipsecs.checkstyle_x.xxxxx ... xフォルダーの内容を<Eclipse PATH> / pluginsの提案されたファイルに置き換えてコピーする必要があります。
提案されたビルドには、私たちのチームのいくつかのパッチが含まれていますが、CheckStyleリリースには含まれていません。
checkstyleプラグインをインストールし、追加モジュールを含むパッチをインストールした後、
[ウィンドウ ] -> [ 設定] -> [作成するチェックスタイル ]、 [ 設定のチェック（ 新規 、 設定 ）を編集します。
表示される構成ウィンドウで、 コーディング問題モジュールのグループに移動し、リストから新しいカスタム宣言順序チェックモジュールを作成する必要があります。
私たちのチームは、CheckStyleの開発に取り組んでいます。 既製のパッチは、 solid90 、 rusya7 、 daniilyar 、 romanivanovのユーザーによって提供されました 。 上記のすべてがhabrayuzerのコミュニティに参加することは特に素晴らしいでしょう。
ここで トピックの続き 。