再フォーマットとバージョン管理

コードのフォーマットが重要です。インデントさえ重要です。そして、小さな改善よりも一貫性が重要です。ただし、プロジェクトには通常、1日目から明確で完全で検証可能で強制的なスタイルガイドがなく、大きな改善がいつでも届きます。たぶんあなたはそれを見つける

SELECT id, name, address
FROM persons JOIN addresses ON persons.id = addresses.person_id;

/として書かれた方が良い

SELECT persons.id,
       persons.name,
       addresses.address
  FROM persons
  JOIN addresses ON persons.id = addresses.person_id;

クエリに列を追加する作業中。これは、コード内の4つのクエリすべての中で最も複雑なものか、数千ものクエリの中でささいなクエリかもしれません。移行がどれほど困難であっても、価値があると判断します。しかし、主要なフォーマットの変更全体でコードの変更をどのように追跡しますか？あきらめて「これが私たちが再び開始するポイントです」と言うか、リポジトリ履歴全体のすべてのクエリを再フォーマットすることができます。

Gitのような分散バージョン管理システムを使用している場合は、最初のコミットに戻り、そこから現在の状態に変更できます。しかし、それは多くの作業であり、作業中は他のすべての人が作業を一時停止する必要があります（または、すべてのマージの母親に備える必要があります）。すべての結果の中で最高のものを提供する履歴を変更するより良い方法はありますか？

• すべてのコミットで同じスタイル
• 最小限のマージ作業

？

明確にするために、これはプロジェクト開始時のベストプラクティスに関するものではなく、大規模なリファクタリングがGood Thing™と見なされたが、追跡可能な履歴が必要な場合に何をすべきかを示しています。バージョンが常に同じように動作することを保証する唯一の方法である場合、履歴を書き換えることは素晴らしいことではありませんが、クリーンな書き換えの開発者の利点はどうですか？特に、書き換えたバージョンが元のバージョンとまったく同じように機能することを保証する方法（テスト、構文定義、またはコンパイル後の同一のバイナリ）がある場合はどうでしょうか？

個別のコミットとして再フォーマットを行います。これにより、履歴への影響が最小限に抑えられ、どのコミットが単なる再フォーマットであり、どのコミットが実際にコードを変更するかが一目でわかるはずです。それはゆがんgit blameで類似している可能性がありますが、それが再フォーマットのみのコミットを指している場合、その前に以前の変更を探すのはかなり簡単です。

VCSの履歴を書き換えないでください。VCSの原則に反します。

書式設定の修正を自動化しようとしないでください。実際の問題ではなく、症状を処理しています（=開発者がコーディング標準に従っていない）。

一般的なドキュメントでコーディング標準とフォーマットのベストプラクティスを定義し、すべての開発者に同意してもらいます。

あなたはGitに言及していますが、それは配布されているからです。DVCSを使用すると、ゲートキーパーワークフローを通じてベストプラクティスを簡単に実施できます。ゲートキーパーは、共通のガイドラインに準拠していないマージ提案（= Gitのプルリクエスト）を拒否します。そして、太字で拒否することを意味します。そうしないと、違反しているコーダーはルールに従うことを気にせず、同じ間違いを繰り返し続けます。

このテクニックは私にとってはうまくいきます。コーダーは自分の作業をマージすることを望んでいるので、最初のいくつかのミスの後、ルールに従うようになります。

既存のコードベースを修正するごとに...おそらく、モジュールごとに、またはプロジェクトにとって意味があるように、徐々に行うことをお勧めします。各ステップで慎重にテストします。馬鹿げているように聞こえるかもしれませんが、書式設定などの些細な変更でも間違いが発生するため、道路での小さな衝突に備えてください。

実際の質問に対する答えは、「あなたはしません」です。ある方法でフォーマットされたコードから、主要なフォーマット変更、およびコードが新しい方法でフォーマットされた後のさらなる変更まで、ロジックの変更をトレースできる現在のSCMツールはありません。そして、あなたはこれを知っています、コードの一部で履歴を失うことは良くありません。

したがって、私はあなたの最初の文に少し矛盾するつもりです。コードのフォーマットはそれほど重要ではありません。かなりいいですが、それは私たちがここにいるものではありません。それの何かない限り、書式設定は、実際に何が起こっているのか理解するのに支障はない...私は理解だけでなく、2スペースのインデントと誰かの旧地獄のような奇妙なK＆Rバリアントコードにダンプ取得することを誰もが（1）を吸うが、並外れ病理学的。その場合、とにかくコードを変更する際に問題が発生するので、気にする必要はありません。

したがって、確立されたコードを厳密に変更して再フォーマットすることは価値がありません。変数名を変更し、長い関数を分割し、コンテンツを変更するリファクタリングのすべてを実行します。はい、ただし再フォーマットするだけではありません。

1）-Windows Clipboard Viewerをしばらく所有していました。全部が1つ、150kのCモジュールでした。さまざまな人が30行以内に5つの異なるブレーススタイルを使用していた場所を見つけました。しかし、そのセクションはうまくいきました。私はそのコードの塊の印刷物を10年間持ち歩いたが、その歴史は重要であり、そのコードは少なくとも3つのソースツリー（Windows 3.x、NT、future 95）にあり、すべてが生きていたため、別の建物で。

しかし、主要なフォーマットの変更全体でコードの変更をどのように追跡しますか？

書式の変更はコードの変更です。コードに対する他の変更と同様に扱います。重要なプロジェクトに取り組んできた人なら誰でも、誰かがコードを「ただ」再フォーマットすることを決めたときに作成されたバグやその他の問題を目にすることでしょう。

しかし、それは多くの作業であり、他のすべての人は作業中に作業を一時停止する必要があります（または、すべてのマージの母親のために準備する必要があります）。

なぜすべてを一度にすべて再フォーマットする必要があるのですか？特に、再フォーマットを行ってもコードの意味が変わらない場合は、ファイルを個別に再フォーマットして、作業中にチェックインできるようにする必要があります。チームの全員にスタイルに同意してもらい（そうでない場合は再フォーマットする意味がありません）、他の作業の過程で全員に再フォーマットを行わせてください。しばらくすると、プロジェクトの残りの部分を中断することなく、ほとんどのコードをカバーできます。

これについては、実行可能な2つのアプローチがあります。

1.コミットフックでコードを再フォーマットする

最初にコードを送信した後にコードを変更するのは難しいですが、再フォーマット手順（astyleなど）がコードを傷つけない場合は、安全な操作です。時間の経過とともに、すべてのコードが最終的に同じに見えることをチーム全体が理解するでしょう。明らかに、包括的なユニット/自動化されたテストを行うことで、何も破られないことが保証されます。

2.すべてのコードの1回限りの再フォーマット

私の経験ではこれはより危険であり、ビッグバン全体の問題を追跡することは困難ですが、それは可能です。後ですべてのテストを実行することが不可欠です。コーディングスタイルの場合、ほとんどの違いは空白の使用を中心にしています-インデントまたは改行。まともなマージツールは、すべての空白の違いを無視するように指示できる必要があるため、これはマージに役立ちます。