なぜコーディング規約が必要とされるのか
保守性や可読性を確保することを目的として設定する
例として以下
- コーディングスタイル(改行、空白、名前などのルール)
- プログラム(画面、バッチ、帳票、APIなど)の標準的な作り方
- プログラムを作る上での推奨事項、禁止事項
- その他、プログラムを作る時のルール全般(レビューの仕方やプログラムの管理方法など)
prettier eslintでカバーできる箇所は設定するのがベスト
code spell checkerなど拡張要素を取り入れるのも良し
命名規則
| 項目 | 命名規則 | 例 |
|---|---|---|
| 変数（useStateも含む） | キャメルケース | variableName |
| 定数 | スネークケース(全大文字) | CONSTANT_NAME |
| 関数 | キャメルケース | functionName |
| 関数の引数 | キャメルケース | functionParameterName |
| コンポーネント | パスカルケース | ComponentName |
| 定数型 | パスカルケース | TypeName |
- codeSpellCheckerで波線売ってる箇所はNG
- 複数形の名詞を利用する場合
- userやfriendが集合を表してるものであるので複数形を使う（users,friends）
- 複数形は単語によって大きく変化するものがあるので注意すること(mouseがmiceみたいな)
コンポーネント作成時の注意点
- React.Fragmentを使用すること
<React.Fragment> // <></>のように省略可（省略を推奨）
<div>
...
</div>
<div>
...
</div>
<React.Fragment/>
- propsは分割代入する（jsx内でpropsを何回も書くことを防ぐ）
const { hoge, fuga } - props;
-
コンポーネント内の最大ステップ数は300までとする
-
同一ファイル内で定義するとき
- 動的に表示可否を変えるパターンがある場合、加工処理を行う場合などで関数化
- 美的感性ではあるが、1コンポーネントが大きかったり、表示条件が多すぎるといったことで可読性の為に非常に小さいコンポーネントで切り出す場合は同一ファイルで定義する
- 三項演算子のような分岐処理があるdom要素の場合、そのまま表示するのではなく、同一ファイル内で切り出して可読性を上げる
型定義
- anyは使わない
- interfaceではなく、typeを使用する interfaceとtypeの違い、そして何を使うべきかについて
export
- page配下以外はexport defaultを使わない（※page配下はNextjsの制約からexport defaultにする必要がある）
- export defaultを使用した場合呼び出しもとはファイルパスさえ指定できていればその処理を取得できてしまい、バグにつながる可能性がある
セマンティックス（適切なマークアップ）を意識
- よく使うところだと
<header> <footer> <main> <aside> <nav>
三項演算子や&&演算子
- nullなら出さない判定をするのであれば、Fragmentなどを返すより&&演算子を使う方が良い
entity.subTitle && <div ...>{entity.subTitle}</div>
関数コンポーネント外への定義
- コードは順に読み下げるように書くべきなので、可能な限りコードのエントリーポイントになるrenderを先頭に書くべき
- レンダリングされるタイミングで関数宣言や関数式は定義されるため
type Propsだけ例外でrender前に書く
※renderの頭で使う為（※css in js で cssを定数定義する為にrender前に書かざるおえない）
テンプレートリテラルに統一する
APIレスポンスデータ
- 開発者ツール等からレスポンスのJSONを直で読むことがまあまあある為、可読であればjsonのままで可読性の高いデータを返してもらうようにお願いする方が良い
外部リンク、内部リンク
- タグで判断できるのとnext/linkが対応するのに一手間必要となる
- aタグは外部リンク
- next/linkは内部リンク
キャッシュ戦略
- APIのキャッシュ、コンポーネントの再描画に巻き込まれてリクエストがポンポン飛ぶようなことを避けられるので、止める必要がないなら使っておくのが良い
Propsの型命名
下記3つに命名パターン
- page.tsx
- component配下のファイル
- 上記ファイル内でのコンポーネント定義
1.2.に関してのコンポーネントではPropsと命名
コンポーネントが特定の種類のPropsを必要とせず汎用的であるため
3に関してはコンポーネント名＋Propsと命名（ex. PanelItem+Props）