リポジトリで定期的にコードフォーマッタを実行することは悪い考えでしょうか？
コードをチェックアウトし、コードフォーマッターを実行し、変更があった場合は変更をコミットしてプッシュバックするcronジョブを作成することを考えています。
オートフォーマッタを使用するほとんどのプロジェクトは、それらをgitフックに配置しますが、数時間ごとに自動的に実行すると、各開発者がgitフックをインストールする負担がなくなります。
私はまだ誰もがクリーンで適切にフォーマットされたコードを書くことを奨励します、そしておそらく私は彼らが書いたコードが再フォーマットされたときにシステムが自動的に開発者にpingできるようにして、彼らが将来何をすべきかを知ることができます。
いいですね、しかしボットではなく、コードの変更をコミットする責任を負う人が欲しいと思います。
その上、これらの変更が何も壊さないことを絶対に確認したいです。たとえば、プロパティとメソッドをアルファベット順に並べ替えるルールがあります。 これは機能に影響を与える可能性があります、たとえば、WCFコントラクトのWSDLファイル内のデータとメソッドの順序。
代わりに、チームのすべての人がチームの標準に従って自動コードフォーマットを適用するのを本当に簡単にしようと思いますエディターまたはIDE内で直接、現在のソースコードファイル（またはその一部） ）。これにより、チームメンバーはフォーマットがいつどのように行われるかをより詳細に制御でき、最終的なフォームでコミットされる前にコードを検査して、テストできますフォーマットが行われた後前ではありません。
チームメンバーのすべてまたはほとんどが同じエディターを使用する場合、これはそれほど難しくありません。全員が別の方法を使用している場合、チームがこれをサポートしている限り、あなたのアプローチが2番目に優れたソリューションになる可能性があります。ただし、夜間のビルドや自動テストなど、追加の安全対策をインストールすることをお勧めしますafter各自動コード変更。
まともなコードを書くのを妨げるだけでなく、VCSでコードの変更として再フォーマットが表示され（希望するものを使用します）、コード開発の歴史的なフローを隠してしまうため、これは悪い考えです。さらに悪いことに、すべてのコードフォーマットアクション（実際には、コードに対するすべての変更）は、手動であれ自動であれ、バグを引き起こす可能性があります。そのため、フォーマッターは、コードレビュー、ユニットテスト、統合テストなどを数か月後まで行わないコードにバグを導入できます。
（コードフォーマッターを自動的に実行する）のは良い考えだと思いがちですが、それは私の意見です。
定期的には実行しませんが、可能であればバージョン管理がコミットする前に実行します。
git の場合、 pre-commitフック を使用すると便利です。 Makefile でビルドされた多くのCまたはC++プロジェクトでは、indentターゲット（ indent または astyle ）そして、貢献者がmake indentを定期的に実行することを期待します。ところで、makeルールを追加して、gitフックがインストールされていることを確認する（またはインストールする）こともできます。
しかし、実際には、それは、技術的な問題よりも社会的な問題です。チームがクリーンで適切にフォーマットされたコードをコミットすることを望みます。これはプロジェクトの社会的ルールです。 （必ずしもすべての社会問題に対する技術的な回答があるわけではありません）。
バージョン管理は、人間の開発者（数ヶ月後の自分自身を含む）間のコミュニケーションを支援するためのほとんどのツールです。あなたのソフトウェアはVCまたはフォーマットを必要としませんが、あなたのチームは必要です。
ところで、さまざまなコミュニティやさまざまなプログラミング言語では、コードの書式設定に対する見方が異なります。たとえば、 Go にはコードの書式設定スタイルが1つしかありませんが、CまたはC++にはたくさんあります。
それは悪い考えだと思います。答えの多くは、実際に誰が行を追加したかを突き止めるのを難しくすることによって歴史を汚し、人々が何でもコミットすることを奨励することをすでにカバーしていますそして、フォーマットボットがそれを処理します。
より良いアプローチは、ビルドツールにフォーマットチェッカーを組み込むことです。 （Javaあり- Checkstyle ）の場合、ビルドに合格した場合（フォーマットを含む）にのみ、ブランチをメインブランチにマージできます。
人々がメインブランチに直接コミットすることを許可する場合（たとえば、Subversionのように）、フォーマットされたコードのみをコミットする規律が全員にあることを確認する必要があります（または、いくつかのチェックが実行された後でサーバーがコミットのみを受け入れるようにする必要があります）。
一般に、それは悪い考えだと思います。原則としてそれは有効なアイデアですが、実際には問題がある可能性があります。コードフォーマッターがコードを壊すことは現実的な可能性であり、開発者に（おそらく正当化された）敵意（たとえば）で応答させるのに必要なフォーマットの実行は1つだけです」オフnow！ "）。
@BasileStarynkevitchの推奨事項と同じように、gitサーバー側のポスト受信フックを使用して、コードスタイルに関する「アドバイスメール」を送信します。
スタイル違反を含むコミットをプッシュすると、git Originサーバーから、スタイルガイドラインに違反していることを通知するメールと、コードを修正することを推奨するメールが送信されます。ただし、ハウススタイルを壊す正当な理由（たとえば、長い文字列が行の長さの制限を超える）がある場合があるため、これは強制されません。
コードベースに悪影響を与えるのがシステムの問題である場合は、コードレビューでコードスタイルの問題を取り上げる時期かもしれません。不十分なコードスタイルはバグを隠し、コードを読みにくくする可能性があるため、有効なコードレビューの問題になる可能性があります。
物事の「社会問題」の側面に加えて、見た目や文体の欠陥を見つけたときに修正するように人々を奨励することは価値があります。標準のコミットメッセージ「Cosmetic」があります。他の開発者が破壊的な変更を含んでいないことを知っているコードスタイルの修正。
@DocBrownが言うように、別のオプションはIDE内でコードスタイルを適用することです。 Visual Studioで CodeMaid を使用して、多くの一般的なスタイルエラーを修正します。これはコードファイルの保存時に実行されます。つまり、悪いスタイルのコードがリポジトリに作成されることはありません...理論的には:-)。
はい、それは悪い考えだと思います。誤解しないでください。それをする理由は素晴らしいように聞こえますが、結果は依然として恐ろしいかもしれません。
追跡されたブランチを引っ張るとマージの競合が発生しますが、少なくともそうなると私は恐れていますが、私は間違っているかもしれません。
今は仕事でテストしたくありませんが、自分で試してみてください。
実際、最近のコミットをチェックアウトすることができます。新しいブランチを作成し、ささいなことをコミットするか、チェリーピックするか、自動コミットなしでマージします。
次に、スクリプトを実行してプルし、結果が恐ろしいマージの混乱である場合は、昼間は絶対にこれを行わないでください。
代わりに、それを夜間ビルドまたは週次ビルドに入れることができます。
しかし、夜間でも悪い考えかもしれません。
すべてが月曜日に終了するため、マージの競合が発生しないことが確実な場合は、毎週実行することもできます。
それ以外の場合は、マージの競合が発生しないホリデーシーズンに年に1〜2回実行します。
しかし、解決策は、コードスタイルの優先度に依存する場合があります。
Gitリポジトリを自動的に作成し、プロジェクトのフックを設定するセットアップスクリプトを作成する方が良いと思います。
または、プロジェクト内の開発者用のフォルダーにフックセットアップスクリプトを含め、それを単にgit自体にチェックインすることもできます。
私が言及していないことの1つは、一連のルールに従って何かをフォーマットしない正当な理由がある場合があるという事実です。時々、99％の時間が理にかなっている所定のガイドラインに反することにより、コードの明快さが改善されることがあります。人間はその呼びかけをする必要があります。これらの場合、自動コードフォーマットは、物事を読みにくくします。
それはひどい考えです。
開発者の同僚の1人がソースファイルに不必要な変更を加えた場合、コードレビューに合格しません。それだけですべての人の生活が困難になります。変更が必要なコードのみを変更します。無意味な変更はマージの競合につながり、エラーが発生する可能性があり、無意味な作業を作成するだけです。
これを定期的に実行したい場合、それはひどいことです。
そして、コードフォーマッタがどのような変更を行うかという問題があります。私はエディターで自動フォーマットを使用していますが、それは適切に機能し、自動フォーマットが完全ではない場合に改善することができます。それを超えるコードフォーマッタを使用する場合、コードを改善するつもりはなく、悪化させることになります。
そして社会問題があります。誰もが自分のコードスタイルを使用するように強制したい人もいますし、より柔軟な人もいます。このようなことは、他のすべての人に自分のスタイルを強制したい「文法ナチ」（意図的なスペル）タイプの開発者によって提案される可能性があります。反発を予想し、柔軟性があり、通常は使いやすい開発者が足を下に置くことを期待してください。
使用するVCSについては言及しませんが、それに応じて、サーバー側のフックを使用することもできます。 gitのようなVCSはこれをサポートしています。プッシュされるバージョンでフォーマッタを実行し、フォーマットされたファイルをプッシュされるバージョンと比較するサーバー側フックをインストールできます。それらが異なる場合、開発者は正しいフォーマットを使用せず、サーバーはプッシュを拒否する可能性があります。これにより、開発者は希望する形式のコードのみをプッシュするように強制され、最初からクリーンなコードを書き込むように促されます。これにより、開発者は正しい形式のコードをテストし、クライアント側に手動でクライアント側をインストールする必要がなくなります。針。
これは、より簡潔なコード形式と、より正確で理解しやすいgit履歴との間のトレードオフです。プロジェクトの性質と、gitの履歴に飛び込む頻度や、何が起こっているのかを理解する責任があるかによって異なります。新しいことに取り組んでいて、下位互換性を維持する必要がない場合、通常、履歴は重要な役割を果たしません。
このアイデアは他のいくつかの回答と似ていますが、私の提案にはコメントできません。
1つのオプションは、commit関数にエイリアス（またはフックなど）を設定することです。これにより、commitされるコードに対して、commitされる前にコードフォーマッターが実行されます。
2つ（またはそれ以上）の結果になる可能性があります。
1）提案された変更をユーザーに示し、変更を適用してコミットする承認を求めます。
2）提案された変更を無視して、元のコードをコミットします。
オプション1で提案された変更を編集する機能など、これらのオプションにさらに柔軟性を追加することもできます。別のアイデア（これらのコーディング標準をプッシュするのがどれだけ難しいかに応じて）は、システムに何らかの種類のレポートを送信することですオプション2が選択されています。
これは、必要に応じてすべてのコードを自動チェックするバランスと、開発者がニーズに合わせて柔軟に対応できるバランスの両方になる場合があります。また、他の回答で述べられているように、フォーマットの違いがあるコードを「自動拒否」しないオプションも可能です。 「私は自動フォーマット修正をレビューして承認しました。コミット」オプションを選択しても、各開発者の作業に対する個人の説明責任は維持され、VCSを台無しにすることはありません。
リポジトリでは実行しませんが、ツールでサポートされている場合は、保存時に実行します。 Eclipseは1つであり、さらに、ソートを含むコードのクリーンアップを行います。
素敵な点は、それがプロジェクトの一部であるため、すべての開発者がプロジェクトで使用できることです。
追加されたボーナスとして、物事がジャンプしないので、マージは大幅に簡素化されます。
コードレビューは、誤ったものを防ぎます。
もう1つの場所は、ビルドの一部にすることです。私の場合、mavenビルドがXMLを再フォーマットし、pomファイルをクリーンアップしてコードを再フォーマットするようにしています。
そうすれば、開発者がプッシュする準備ができたら、プルリクエストのためにすべてクリーンアップされます。