回答:
これを行うことが非常に重要だと思います。その理由は次のとおりです。
あなたがそれをするなら、誰もがすべてのコードをチェックインすることをお勧めします、そして一人がコードベース全体にわたって再フォーマットを行い、それからすべてをチェックインして、フォーマットのための1つの「巨大な」変更セットがあります（誰でも無視できます）が、その後、すべての差分は実際のコード差分になります。
少しずつやると、実際のコードの変更とフォーマットの変更が混ざり合い、変更の土地で物が不必要に乱雑になります。
人々が利点を追加しているように見えるので、ここで自分の答えを投げます。私が不利だと思うものは：
簡単に言えば、自動化されていない規則のセットは最小のスタイル/読みやすさの要件を設定し、自動化された規則は最小値と最大値を設定します。
VB（バージョン5かもしれません）を見て、それについて最も面倒なことの1つを見つけたのは、コードを強制的に再フォーマットし、その基本的なフォーマットを超えるものを削除することでした。
主な欠点は、本当に重要な場所でカスタム書式設定が失われることです。
特定の条件のいずれかが存在するが満たされていない場合に失敗する典型的な健全性チェックif（）を想像してください...
if(
(user.id == TEST_ID)
||(
(user.id == UserID)
&&(
( user.type == HUMAN_USER && user.name.size() >= MIN_NAME )
||( user.type == EMULATION && input.source != SOURCE_INTERNAL ))
&& ( user.email == NULL || emailValidator.isValid(user.email))
&& ( (user.phone == NULL) == (user.type == EMULATION) )
// several more lines like this.)
){ /* handle results */ }これは、条件の論理構造に従う合理的なインデントのおかげで読み取り可能です。
現在、自動化ツールには、さまざまな条件を関連する行に論理的に分離する手掛かりがありません。各行が3〜4個の条件を1行にまとめ、次の条件を半分に分割する理由はありません。または、行ごとに1つの比較式を分割します。画面上でもきれいに見えるかもしれませんが、ロジックは失われます。
それはあなたのニーズに依存しますが、いくつかの制約は非常に役立ちます。例えば、すべてのif（）の後に中括弧が続くべきです。
その場合を考慮してください：
if( x == 0 )
return foo;
//do something else
return bar;ifケースにログを追加したい場合は、誤って次のように書きます：
if( x == 0 )
log.info("x was 0");
return foo;
//do something else
return bar;そして、突然あなたのメソッドは常に戻ります foo。
編集：自動書式設定ではなく、スタイルチェックです。その回答も話題にならなかった場合は申し訳ありません。:)
私の経験では、それは良いことです。コードがないと、コード比較で空白の書式設定の混乱が頻繁に表示され、実際のコード変更が隠される場合があります。私の経験では、誰かの書式設定をいじることは、特にチーム全体の一貫性の潜在的な利点に関して、明らかにされた罪ではありません。