コードレビュー時にコードの品質以外の点で指摘されたことはないでしょうか？
設計以外で指摘を受けることはコードレビューする側の負担となってしまいます…
この記事では、最低限原則として知っておいた方がいいことや不用意な指摘を減らすためのプラグインを伝えられたらと思います！
「code-spell-checker」を入れる
vscodeを利用している場合であれば「code-spell-checker」を入れておきましょう！
たまに動いていない時があるので、動いているか時々確認してあげてください…
命名ルールに特例を作らない
例えばTailwindCSSを利用している環境だったとします。
TailwindCSSを拡張し、新しくclassを追加しようとした時にTailwindCSSのルールに沿わないclassは作らないということです。
// NG:キャメルケース
const extendColors = {
onSurface: '#ff49db';
}
// OK：ケバブケース
const extendColors = {
'on-surface': '#ff49db';
}
細かいですが、1つでも異なった形式で定義すると統一感が失われ、たった1例だけ許したはずがその後例外を生み続ける火種になる可能性があるので注意が必要です。
Reactではイベントハンドラ関数に「handle」をつけて命名する慣習があるので覚えておきましょう！
基本ルールを知っておく
それぞれの言語には暗黙のルールのようなものが存在します。
一般的な通例に沿わないコーディングはノイズになり、後の開発者を混乱させてしまうので世の中の一般的な書き方を知っておけると良いと考えます。
ただ、ルールをそのまま採用するかはチームで認識をすり合わせる必要があります。
インデントのルールは4つのスペースを利用すると記載がありますが、スペースは2つを利用することもあると思います。
インデント4つだと深い感じるので2つが良いと考えています
全てのルールを採用するわけではなく、命名ルールや書き方は世間一般に公開されているルールを採用することで新規Joinするメンバーにとっても優しい環境になるのではないかと考えています。
ちょっとした違和感を大切にする
たとえば下記のような例です。
type Props = {
children: string
}
const COmponent = ({ children }) => {
return <p>{children}</p>
}
childrenはstringだけにしたいと考えてchildrenをstging型で定義しました。
ミスではないのですが、childrenはHTMLも要素の中に含まれることがあります。
というよりchildrenが利用される場面はむしろHTMLも含めたいケースがほとんどではないかと思っています。
childrenの型はReactNodeを選択するのが一般的なのでstringの型を指定するのは違和感がある
間違いではありませんが、コンポーネントで型定義を強めすぎると柔軟性がなくなり扱いは難しくなります。
コンポーネントを別ドメインでシェアできるように想定して作成するのであれば、あえて緩く作ってコンポーネントを利用するアプリケーション層で型を厳格にするなどを検討できると良いでしょう。
まとめ
私も全てができているわけではありませんが、意識できることでレビューワーとのコミュニケーションコストは下がると考えています！
世の中の標準ってなんだろう？は事前にキャッチできなければ、レビューワーとレビューの方針は何かすり合わせておけると良いと考えます！