私は、世界中に約 20 人の開発者がいる大規模なJava EE / Maven / Hudson / Perforceプロジェクトのビルドを維持しています。
コード フォーマットのインプレース ソリューションは、開発者がビルドを実行するときにJalopyを使用してコードベースをフォーマットすることです。これにより、フォーマットされていないコードはチェックイン前にフォーマットされます。
このソリューションの主な問題は、開発者がチェックインする前に完全な Maven ビルドを実行しない場合 ( Eclipseから単体テストを実行するとします)、コードがフォーマットされないことです。その後、ファイルを編集する次の開発者は、フォーマッタを実行した後、コードの無関係なセクションに非常に多くの差分を作成する可能性があります。
大規模なプロジェクトで、どのソースフォーマット戦略が最も効果的でしたか? 私が検討したもう 1 つのオプションは、自動化されたプロセスを使用して毎晩フォーマットすることです。
Maven ビルドは、Checkstyleなどを使用してフォーマット エラーを報告するだけで、コードを自動的にフォーマットすることはありません。それがあなたの説明が暗示しているように見えました。このようにして、ビルド時にエラーが開発者/Hudson に報告され、必要に応じて解決できます。
また、 Sonarなどのツールを使用して、フォーマット エラーの履歴を長期にわたって保持することをお勧めします (タイム マシン機能を参照してください)。
プロジェクトに一貫したフォーマットを適用するには、それを自動的に行うようにツールを構成する必要があります。私は次のことを提案します：
Eclipseフォーマッター
Eclipseの場合、[設定]（[Java]->[コードスタイル]->[フォーマッター]）に、プロジェクトのフォーマット方法を構成できるオプションがあります。新しいプロファイルを作成し、そこに構成を配置します。
終了すると、エクスポート機能があります（よく隠されているので、[編集]、[エクスポート]の順にクリックします）。がインポートできるように、構成をチームの他のメンバーに渡します。
Eclipseの保存アクション
フォーマッターを構成したままでも、開発者がコミットする前にコードをフォーマットすることを保証するものではないため、自動フォーマットを構成する必要があります。
再度[設定]に移動し（[Java]->[エディター]->[アクションの保存]）、[ソースコードのフォーマット]を選択します。このようにして、ファイルの保存中にコードがフォーマットされます。
EclipseCheckstyleプラグイン
一部の開発者はこれらの手順を正しく実行するのを忘れている可能性があるため、それを見つける方法が必要です。
Eclipse用のCheckstyleプラグインをインストールします。
プラグインをインストールすると、プラグインの構成を作成できます。その後、構成をチームの他のメンバーにエクスポートしたり、サーバーにアップロードして構成をリモートで参照したりすることができます。
リモート構成を持つことの利点は、maven-checkstyle-pluginからも参照でき、CIサーバーで起動することでレポートを提供できることです。
ハードコアになりたい場合は、基本構成（フォーマッターによって自動的に行われる構成）を警告ではなくエラーに設定して、誤って構成された日食を持つ開発者がコミットする前にエラーを確認できるようにすることができます。
事前構成されたEclipse
次のレベルに進みたい場合は、事前構成された日食を作成し、そのバージョンを開発者に配布して、開発者が何もする必要がないようにします。
副作用ボーナス：開発プラットフォームでのバージョンの不整合を回避します。構成管理は、ソースコードだけでなく、開発ツールにも関係します。物事をより予測可能に保ちます。
これを処理する 1 つの方法は、 JalopyやJIndent 、さらには Eclipse 組み込みコード フォーマッター (コマンド ラインから呼び出すことができる)などを使用して、プレコミット フックでコードをフォーマットすることです。私の知る限り、これは、コミットする前に自動ビルドを実行するよう強制できない場合に、バージョン管理されたコードが常に適切にフォーマットされていることを保証する唯一の方法です。しかし、Perforce が pre-commit フックをサポートしているかどうかはわかりません。
そうでない場合は、ビルド時にJalopy Maven プラグインまたはMaven Checkstyle プラグインを使用し、ルールが破られたときにビルドを失敗させる (そして CI エンジンに報告させる) という別のオプションがあります。ただし、装飾的なもののビルドの失敗はかなり面倒です。
したがって、実際には、コードをフォーマットするために毎晩プロセスを実行することが代替手段になる場合があります。その場合、Jalopy Maven プラグインまたはその他の言及されたツールが役立つ場合があります。実際には、このジョブに Maven を使用するかどうかによって異なります。
これについて私が見た最良の解決策は、CXFが採用したアプローチであり、Maven、Eclipse、Checkstyle、および PMD の接続で詳しく説明されています。
別の返信で言及されている Eclipse-cs プラグイン Dimitris を使用して、checkstyle をEclipseと統合します。これにより、Eclipse のコードがコードのフォーマット規則に違反している場合、Eclipse はエラーを生成できます。また、 checkstyle とMavenを統合しているため、コードが checkstyle ルールに準拠していない場合、検証ステップは失敗します。また、Eclipse 内で定義された自動フォーマット規則の冗長セットも備えているため、checkstyle の標準に合格するコードを迅速にフォーマットすることが容易になります。
これは、Eclipse の多くの構成を意味します。これらは、必要な checkstyle/autoformatting 構成を含む CXF 固有のワークスペースを生成する Maven プラグインのコレクションをまとめることで、このステップを自動化します。
すべて (または大部分) の開発者が Eclipse を使用している場合は、チームの好みに合わせて書式設定ルールと保存アクションをエクスポートし、全員が同じ設定を共有できるようにすることができます。
Perforce でチェックイン ルールを設定して、チェックイン時にコードをフォーマットできますか? 私は perforce を使用したことがないのでコメントできませんが、これは、チームでコードの書式設定の強制オプションについて話し合ったときに適切だと考えた種類のものです。
適切なフォーマットが不可欠な場合は、チェックイン時に独自のフォーマットを実行するようにPERFORCEを構成し、ソースファイルのフォーマットされたバージョンが送信されたものと異なる場合はコミットを拒否するように指示します。
個人的には、Eclipse Save Actionsを使用し、保存時に再フォーマットするように指示します。私たちには十分です。
これはあまり役に立たないかもしれませんが、Go 言語のソース ツリーは、設定したコマンド ライン アプリを使用して、プッシュしたものを自動的にフォーマットします。これは Perforce ではなく Mercurial で行われます。しかし、彼らがどのようにそれを行ったかを見ることができるかもしれません。詳細はgolang.orgのどこかにあるはずです。