「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の型を指定するのは違和感がある

間違いではありませんが、コンポーネントで型定義を強めすぎると柔軟性がなくなり扱いは難しくなります。

コンポーネントを別ドメインでシェアできるように想定して作成するのであれば、あえて緩く作ってコンポーネントを利用するアプリケーション層で型を厳格にするなどを検討できると良いでしょう。

私も全てができているわけではありませんが、意識できることでレビューワーとのコミュニケーションコストは下がると考えています！

世の中の標準ってなんだろう？は事前にキャッチできなければ、レビューワーとレビューの方針は何かすり合わせておけると良いと考えます！