コードレビューガイドライン: Add w=1のtips

documents/forCodeReview/code_review.md

@@ -251,6 +251,16 @@ SQL:
   - 差分を小さくするために、コードベースの改善活動を止めるのは本末転倒である（良いモノを作るためにコードレビューをしている面がある）
 - 必要に応じて、プルリクエストの分割を検討する
 
+::: tip GitHubやGitLabでは空白のみの差分を無視できる
+
+GitHubやGitLabではURLの最後に、 `?w=1` を付与することで、空白のみの差分を無視することができる（画面上からの設定も可能）。
+
+例えば、Markdownテーブルに項目を編集するとフォーマッタにより大きな差分が出ることが多く、変更に対する心理的ハードルが上がってしまう。しかし、このオプションを利用することでレビュアーの負荷は下がり本質的なレビューに集中できる。もし、レビュアーがこのオプションを知らないようであれば、 `?w=1` つきのURLをプルリクエストのDescriptionやレビューコメントで追記すると良い。
+
+- [Ignore white space in code review - The GitHub Blog](https://github.blog/news-insights/product-news/ignore-white-space-in-code-review/)
+
+:::
+
 ## ファイルの移動やリネームと同時に大きく編集しない
 
 リファクタリングや構成の整理で、ファイルの移動やリネームを行う場面は多々ある。
@@ -550,18 +560,18 @@ GitHubでのコードレビューは、`Start a review` を行うと `Submit rev
 - 「可読性が低いです」 「{任意の非機能要件}を満たしていません」といったコメントで終始せず、具体的にどの部分を、どのように修正して欲しいかをフィードバックする
 - もし、修正する部分を（教育目的などで）レビュイーに考えてほしい場合は、その旨をコメントに追記する。レビュアーのお気持ちあてゲームにしないこと
 
-## 出典があれば追記できるとベター
-
-指摘内容の補足情報があれば追加するとベターである。例えば、「◯◯の観点で、このコードは△△の懸念があるため、□□□になるように修正をお願いします。公式ブログの{URL}にも記載があり、参考にできると思います。」といった形式である。
-
-レビュイーが自分で調べれば事足りる場合もあるが、レビュアー側が出典を示すことで納得感が増す。また、誤った記事（過去のバージョンの記事や、見当違いの記事）を読んでしまい空回ってしまうことも、探す手間も減る。
-
 ## 指摘内容を論理的に説明できないのであれば、コメントすべきではない
 
 「なんとなく汚いです」は指摘ではない。悪いコードだと感じたのであれば、相手が納得できるように論理的に説明する。論理的に説明できないのであれば、指摘をすべきではない。
 
 - 引用: [デキるプログラマだけが知っているコードレビュー7つの秘訣 | PPT](https://www.slideshare.net/rootmoon/7-37892729) p26
 
+## 出典があれば追記できるとベター
+
+指摘内容の補足情報があれば追加するとベターである。例えば、「◯◯の観点で、このコードは△△の懸念があるため、□□□になるように修正をお願いします。公式ブログの{URL}にも記載があり、参考にできると思います。」といった形式である。
+
+レビュイーが自分で調べれば事足りる場合もあるが、レビュアー側が出典を示すことで納得感が増す。また、誤った記事（過去のバージョンの記事や、見当違いの記事）を読んでしまい空回ってしまうことも、探す手間も減る。
+
 ## なるべく1度のレビューで指摘し切る
 
 レビュイーからすると、レビューの「依頼1→指摘1→対応1→確認依頼1→別の指摘2→対応2→確認依頼2→別の指摘3→…」と、依頼のたびに指摘をもらうとタスクの予実管理も作業見積もりも建てられずストレスである（ムービング・ゴールポストである）。