JSONの整形差と意味のある変更を分けてレビューする

4つの分類で見る

まず両方をJSONとして解釈します。値が同じで空白・objectのキー順だけが違う場合は整形差です。それ以外は変更の種類を分けます。

整形差と意味のある差を分ける

format-before.json と format-after.json は、空白とキー順が違っても解釈後の値は同じです。一方、semanticの組では、値・型・配列順が別々のレビュー理由になります。

/version  1 → 2          value
/enabled  true → "true"   type
/items    [a,b] → [b,a]   array-order

配列順が意味を持つかは受け手の契約次第です。順序変更を自動で安全扱いしません。

レビュー前の確認順

1. 両方をparseし、空白とobjectのキー順を意味のある変更と混同しない。
2. 変更ごとにJSON Pointer、観測値、分類を記録する。
3. 値変更・型変更は意図と受け手のschemaを確認する。
4. 配列順は順序の契約を確認し、分からなければ保留する。
5. before/afterと判断表を一緒に渡し、patchを自動適用しない。

このガイドはブラウザー内の静的資料です。入力・ファイル・検証結果を外部へ送信・保存しません。

整形差だけでも安全の証明ではない

整形差がないことは、値や型が正しいこと、配列順が受け手の契約に合うことを保証しません。反映前に変更の意図・schema・実行環境を別に確認します。