VCSを使用するときにコードをフォーマットするのは悪いことですか？

コミットする前に、ほとんどの場合、コードを適切にフォーマットするようにフォーマットします。私のチームのほとんどは、実際には気にせず、常にコードを適切にフォーマットしません（コードに影響を与えないが、保守しようとするときの可読性に影響を与える小さなこと）。

私は最近、「保存時にフォーマット」オプションを持つVSパワーツールをインストールし、以前にフォーマットされていないファイルに変更を加えました。開発VPが私のところに来て、フォーマットのために私をre責しました。なぜなら、マージツールでは、1行または2行ではなく、ファイル全体がほとんど変更されているように見えるためです（したがって、彼は私が簡単に変更したものを正確に見ることができません）将来的に保存時にフォーマットを無効にするように言われました。私はその懸念を理解していますが、フォーマットされていないコードをソートすることは時々困難であり、IMOはとにかく常に適切にフォーマットされるべきです。気まぐれに再フォーマットするだけではないことに注意してください。しかし、コードを書くときは、パワーツールを使用するか、キーコマンドを押してテキストをフォーマットし、読みやすくします.SVNでは次のように表示されます変更。

だから私は尋ねます、常に実際にコードをフォーマットすることは悪いことですか？彼の懸念は、コードが読み取り可能であることを確認するよりも妥当ですか？

最初に、チームはフォーマット規則を選択し、それに従う必要があります。あなたは合意に達し、全員がそれに固執するようにする必要があります。これは、あなたが自分で行うだけではありません。

あなたの本当の質問に関しては。コードのフォーマットは悪いことではありません。悪いのは、コードの変更と同じコミットで大きなフォーマット変更を行うことです。チームが物事をどのようにフォーマットするかについて合意に達したら、コードを1回通過させてすべてをフォーマットします。それ自体を確認してください。コミットメッセージは、変更が単なる空白であり、機能しないことを明確にします。その後、機能的な変更を行う必要がある場合、それらは異なるコミットにあるため、明確に見ることができます。

いいえ、フォーマットコードは非常に重要です。ただし、コミットは2つのグループで行う必要があります。

1. 外観の変更 -コードを読みやすくするもの。
2. 他の変更 -コードに影響を与える他のすべて。

コミットメッセージを使用して、化粧品のみが変更されたことを示します。より実質的な変更を検索する場合、これらは簡単にスキップできます。

両方にポイントがありますが、両方ともあなたがほしいものを手に入れることができます。最初にコードをフォーマットし、その変更のみをチェックインします。次に、機能の変更を行い、2番目のステップとしてチェックインします。

私も書式設定の専門家なので、ここにいくつかのヒントを示します。

• 必須の最初のステップ：タブ対スペース、ブレースの位置、コメントスタイルなど、いくつかの基本的なフォーマットの標準についてチームに同意してもらいます。つま先に。

• 変更したコードの周りのフォーマットのみをクリーンアップします。1つの関数だけを変更する場合は、その関数をクリーンアップしてください。少なくとも時間が経つにつれて、コードの見栄えが良くなります。

• 他のコードを変更せずに、主要なフォーマットのオーバーホールを別個のコミットとして実行します。変更後のコードと変更前のコードを比較する可能性が低い場合にのみ、これらを実行する必要があります。私は通常、そのコードの大規模な開発の前に最初にクリーンアップを行います。

• 重要な変更と重要でない変更の言語依存のマーキングを実行できる優れたdiffツールを入手してください。私のお気に入りの比較Beyond Compareは、実際のコードの変更をある色でマークし、空白/コメントを別の色でマークします。

もう1つのヒントを編集します。

• 言語によって言語は異なりますが、コードの実際の表面的な変更については、大規模なクリーンアップの前後にコンパイル済みのバイナリを比較して、完全に削除されていないことを確認できる必要があります。

次の場合を除き、他の人のコードを再フォーマットして変更をコミットすることはできません。

• あなたはチームのコーディング標準を確立しようとしているマネージャーです
• チームのコーディング標準に準拠するために、マネージャーからコードをクリーンアップするように依頼されました
• チームのコーディング標準を遵守するために、チームにいない開発者からコードをクリーンアップしています。

すべての場合において、私がチームのコーディング標準を参照していることに気付くでしょう。私は、チームの合理的で合意されたコーディング標準を強く信じています。それらがある場合、元の開発者は戻ってチームの標準に準拠するためにコードをクリーンアップする必要があります。あなたは彼らの後ろでそれを行うべきではありません。あなたが標準を持っていない（そしてそうするべきである）なら、あなたの哲学、特に彼らの後ろに固執するために、他のチームメンバーのコードを修正するべきではありません。あなたはチームの一員であり、コーディング標準は重要ですが、チームメンバー間の信頼と尊敬も重要です。