リポジトリでコードフォーマッタを定期的に実行するのは悪い考えでしょうか？

私は、コードをチェックアウトし、その上でコードフォーマッタを実行し、変更があった場合は変更をコミットしてプッシュするcronジョブを作成することを考えています。

オートフォーマッタを使用するほとんどのプロジェクトは、それらをgitフックに入れますが、数時間ごとに自動的に行うと、各開発者がgitフックをインストールする負担がなくなります。

私はまだ誰もがクリーンで適切にフォーマットされたコードを書くことをお勧めします。おそらく、書いたコードが再フォーマットされたときにシステムが開発者に自動的にpingできるようにして、彼らは将来何をすべきかを知っています。

良さそうに聞こえますが、ボットではなく、コードの変更をコミットする責任者を希望します。

また、これらの変更が何も壊さないことを絶対に確認する必要があります。たとえば、プロパティとメソッドをアルファベット順に並べるルールがあります。これは、WCFコントラクトのWSDLファイル内のデータとメソッドの順序など、機能に影響を与える可能性があります。

代わりに、チームの全員が、エディターまたはIDE内でチームの標準に応じた自動コードフォーマットを現在のソースコードファイル（またはその選択された部分）に直接適用できるようにすることを試みます。これにより、チームメンバーは書式設定の方法とタイミングをより詳細に制御でき、最終フォームでコミットされる前にコードを検査し、書式設定が行われる前ではなく、行われた後にテストできます。

すべてのまたはほとんどのチームメンバーが同じエディターを使用している場合、これはそれほど難しくないはずです。全員が別の方法を使用している場合、チームがこれをサポートしている限り、アプローチは2番目に最適なソリューションになる可能性があります。しかし、私はナイトリービルドと実行されている自動テストのようなあなたは、インストールされ、余分な安全対策を持ってお勧めした後、各コードの自動修正。

それは悪い考えです、それは人々がまともなコードを書くことを思いとどまらせるためだけでなく、VCSでコードの変更として再フォーマットが表示されるためです（私は希望するものを使用します）、コードの開発の歴史的な流れを隠します。さらに悪いことに、すべてのコードフォーマットアクション（実際にはコードに対するすべての変更）には、手動であるか自動であるかにかかわらず、バグが発生する可能性があります。そのため、フォーマッターはコードにバグを導入する可能性がありますが、バグは数か月後までコードレビュー、単体テスト、統合テストなどを通過しません。

コードフォーマッタを自動的に実行することは良い考えだと思いがちですが、それは私の意見です。

定期的に実行しませんが、可能であればバージョン管理がコミットされる前に実行します。

gitの、事前にコミットフック有用であろうやっ。Makefileを使用してビルドされた多くのCまたはC ++プロジェクトでは、いくつかのindentターゲット（indentまたはなどの適切なコードフォーマッタを実行）を追加してastyleおり、貢献者がmake indent定期的に実行されることを期待しています。ところで、makegitフックがインストールされている（またはインストールされている）ことを確認するためのルールを追加することもできます。

しかし、実際には、技術的な問題というよりも社会的な問題です。チームにきれいできれいにフォーマットされたコードをコミットしてもらいたい、それがプロジェクトの社会的ルールです。（すべての社会問題に対する技術的な答えが常にあるとは限りません）。

バージョン管理は、主に人間の開発者（数か月後の自分自身を含む）間のコミュニケーションを支援するツールです。ソフトウェアにはVCやフォーマットは必要ありませんが、チームには必要です。

ところで、さまざまなコミュニティとさまざまなプログラミング言語は、コードのフォーマットに関するさまざまな見解を持っています。たとえば、Goには1つのコードフォーマットスタイルしかありませんが、CまたはC ++には多くのスタイルがあります。

それは悪い考えだと思います。回答の多くは、誰が実際に行を追加したのかを特定するのを難しくすることで歴史を汚し、人々が何でもコミットすることを奨励し、フォーマットボットがそれを処理することをすでにカバーしています。

より良い方法は、ビルドツールにフォーマットチェッカーを組み込むことです。（JavaにはCheckstyleがあります）次に、ビルドが（フォーマットを含む）成功した場合にのみ、ユーザーがブランチをメインブランチにマージできるようにします。

（たとえばSubversionのように）人々がメインブランチに直接コミットできるようにする場合は、すべての人がフォーマットされたコードのみをコミットする規律を持っていることを確認する必要があります）。

一般的に、それは悪い考えだと思います。原理的には有効なアイデアですが、実際には問題になる可能性があります。コードフォーマッターを使用してコードを壊すことは現実的な可能性であり、開発者に（おそらく正当な）敵意を持って対応させるために1回のフォーマッティングを実行するだけです（たとえば、「お粗末なコードフォーマッターがビルドを中断しました。今すぐオフにします！」）。

@BasileStarynkevitchの推奨と同じように、gitサーバー側の受信後フックを使用して、コードスタイルに関する「アドバイスメール」を送信します。

スタイル違反を含むコミットをプッシュすると、git originサーバーからメールが送信され、スタイルガイドラインに違反したことを通知し、コードの修正を推奨します。ただし、ハウススタイルを破る正当な理由（たとえば、行の長さの制限を超える長い文字列）があるため、これを強制しません。

コードベースに悪影響を与えるシステムの問題である場合は、コードレビューでコードスタイルの問題を取り上げるときが来ている可能性があります。コードスタイルが適切でないと、バグが隠され、コードが読みにくくなる可能性があるため、有効なコードレビューの問題になる可能性があります。

物事の「社会的問題」の側面に追加するために、見かけ上の欠陥や文体の欠陥を見つけたときに修正することを人々に奨励する価値があります。標準のコミットメッセージ「Cosmetic」があります。他の開発者が重大な変更を含まないことを知っているコードスタイルの修正。

@DocBrownが言うように、別のオプションはIDE内でコードスタイルを強制することです。Visual StudioでCodeMaidを使用して、多くの一般的なスタイルエラーを修正します。コードファイルを保存すると実行されます。つまり、悪いスタイルのコードは、理論的にはリポジトリに入れることはできません:-)。

はい、それは悪い考えだと思います。誤解しないでください、それをする理由は素晴らしいように聞こえますが、結果はまだ恐ろしいかもしれません。

追跡されたブランチを引っ張るときにマージの競合が発生しますが、少なくとも私はそうなるのではないかと心配していますが、間違っているかもしれません。

今は仕事でテストしたくありませんが、自分で試してみてください。

実際、最近のコミットをチェックアウトできます。新しいブランチを作成したり、ささいなことをコミットしたり、チェリーピックしたり、自動コミットなしでマージしたりします。

次に、スクリプトを実行し、プルします。結果がひどいマージ混乱である場合は、間違いなく昼間にこれを実行しないでください。

代わりに、夜間ビルドまたは毎週ビルドに入れる可能性があります。

しかし、毎晩でも悪い考えかもしれません。

すべてが月曜日に終了するため、マージの競合が発生しないことが確実な場合は、毎週実行することもできます。

それ以外の場合は、マージの競合が発生しないホリデーシーズンに1〜2回実行します。

ただし、ソリューションはコードスタイルの優先度に依存する場合があります。

gitリポジトリを自動的に作成し、プロジェクトのフックを設定するセットアップスクリプトを作成する方が良いと思います。

または、プロジェクト内の開発者用のフォルダーにフックセットアップスクリプトを含め、それを単にgit自体にチェックインすることもできます。

私が言及したことはありませんが、ルールのセットに従って何かをフォーマットしない正当な理由が時々あるという事実です。時には、99％の時間に意味がある所定のガイドラインに反することで、コードの明瞭さが改善されます。人間はその電話をかける必要があります。これらの場合、自動コード書式設定は物事を読みにくくします。

それはひどい考えです。

開発者の同僚の1人がソースファイルに無償で変更を加えた場合、コードレビューは合格しません。誰にとっても人生が難しくなります。変更が必要なコードを変更しますが、それ以外は何も変更しません。無意味な変更はマージの競合につながり、それがエラーにつながり、無意味な作業を作成するだけです。

定期的にこれを実行したい場合、それはひどいです。

そして、コードフォーマッタがどのような変更を加えるのかという疑問があります。私はエディターで自動フォーマットを使用していますが、それはかなりうまく機能し、自動フォーマットが完全ではない場合に改善できます。それを超えるコードフォーマッターを使用する場合、コードを改善するつもりはなく、悪化させるでしょう。

そして、社会問題があります。すべての人に自分のコードスタイルを使用するように強制したい人がいますが、より柔軟な人もいます。このようなことは、他のすべての人に自分のスタイルを強制したい「グラマーナチ」（意図的に綴る）タイプの開発者によって提案される可能性があります。反発を期待し、柔軟で通常は使いやすい開発者が足を踏み入れることを期待してください。

使用するVCSについては言及していませんが、それに応じて、サーバー側のフックを使用することもできます。gitのようなVCSはそれをサポートしています。プッシュされるバージョンでフォーマッタを実行し、フォーマットされたファイルをプッシュされるバージョンと比較するサーバー側フックをインストールできます。それらが異なる場合、開発者は正しいフォーマットを使用せず、サーバーはプッシュを拒否する可能性があります。これにより、開発者は目的のフォーマットのコードのみをプッシュするため、最初からクリーンなコードを記述するように強制され、開発者は正しくフォーマットされたコードをテストし、クライアント側を手動でインストールする必要がなくなりますフック。

よりクリーンなコード形式と、より正確で理解しやすいgit履歴とのトレードオフです。プロジェクトの性質と、何が起こっているのかを理解するためにgitの履歴または非難にどのくらい頻繁に飛び込むかによって異なります。何か新しいことに取り組んでいて、後方互換性を維持する必要がない場合、通常、履歴は重要な役割を果たしません。

このアイデアは他のいくつかの答えに似ていますが、提案をコメントすることはできません。

1つのオプションは、コミット関数にエイリアス（またはフックなど）を設定することです。これにより、コミットされる前に、コミットされるコードでコードフォーマッタが実行されます。

2つ（またはそれ以上）の結果があります。

1）ユーザーに提案された変更を表示し、変更の適用とコミットの承認を求めます。

2）提案された変更を無視し、元のコードをコミットします。

オプション1で提案された変更を編集する機能など、これらのオプションに柔軟性を追加することもできます。別のアイデア（これらのコーディング標準のプッシュの難易度によって異なります）オプション2が選択されています。

これは、開発者が必要に応じて柔軟に対応できるようにする一方で、必要なすべてのコードを自動チェックすることのバランスが取れている場合があります。また、他の回答に記載されているように、フォーマットの違いがあるコードを「自動拒否」しないオプションも可能です。「自動書式修正を確認および承認しました。コミット」オプションは、各開発者の作業に対する個人的な説明責任を維持し、VCSを混乱させません。

リポジトリでは実行しませんが、ツールでサポートされている場合は保存時に実行します。Eclipseはその1つであり、さらに、ソートを含むコードのクリーンアップを行います。

良い点は、それがプロジェクトの一部であるため、すべての開発者がプロ​​ジェクトのためにそれを取得することです。

ボーナスが追加されると、物事が飛び回らないため、マージが大幅に簡素化されます。

コードレビューにより、誤ったレビューが防止されます。

私がそれをする別の場所は、それをビルドの一部にすることです。私の場合、mavenビルドがXMLを再フォーマットし、pomファイルをクリーンアップし、コードを再フォーマットするようにしています。

そのようにして、開発者がプッシュする準備ができたら、すべてプル要求のためにクリーンアップされます。