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

良さそうだが、私はボットではなく、人がコード変更をコミットする責任を持つことを望む。

それに、その変更が何も壊さないことを絶対に確認したい。例えば、プロパティとメソッドをアルファベット順に並べるルールがあります。**例えば、WCFコントラクトのWSDLファイルにおけるデータとメソッドの順序などです。

私はその代わりに、チームの全員が、エディタやIDE 内で直接、チームの標準に従って、現在のソースコードファイル(またはその一部)に自動的なコード書式設定を適用することを、本当に簡単にできるようにします。こうすることで、チームメンバーは書式設定の方法とタイミングをよりコントロールできるようになり、最終的な形でコミットされる前にコードを検査し、書式設定の前ではなく、書式設定の後にテストできるようになります。

チームメンバーの全員またはほとんどが同じエディターを使っているのであれば、これはそれほど難しいことではありません。もし全員が違うエディターを使うのであれば、チームがこれをサポートしている限り、あなたのアプローチは2番目に良い解決策かもしれません。しかし、夜間ビルドや自動テストなど、自動コード修正の後に実行されるような、特別な安全対策を導入することをお勧めする。

私は（コードフォーマッタを自動的に実行するのは）良いアイデアだと信じているが、それはあくまでも私の意見だ。

定期的に実行するつもりはないが、可能であればバージョン管理のコミット前に実行したい。

git]1では、それを行うpre-commit hookが便利でしょう。Makefile]3を使ってビルドされた多くのCやC++のプロジェクトでは、indentやastyleのような適切なコードフォーマッタを実行する indent ターゲットを追加し、貢献者が定期的に make indent を実行することを期待しています。ちなみに、gitフックがインストールされていることを確認するために(あるいはインストールするために)makeルールを追加することもできます。

しかし、実際には それは 技術的な 問題というよりも 社会的な 問題なのです。 あなたはチームにきれいできれいな書式のコードをコミットしてほしいと思っていますし、それはあなたのプロジェクトの社会的なルールなのです。(すべての社会的問題に技術的な答えがあるとは限らない）。

バージョン管理は、ほとんどの場合、人間の開発者（数ヶ月後のあなた自身を含む）間のコミュニケーションを助けるためのツールです。あなたのソフトウェアにはVCやフォーマットは必要ありませんが、あなたのチームには必要です。

ところで、異なるコミュニティや異なるプログラミング言語では、コードのフォーマットに関する見解が異なります。例えば、Goには1つのコード書式しかありませんが、CやC++にはたくさんの書式があります。