基礎的なレビュー項目

評価項目	タグ	補足
final と const を適切に利用しているか	Dart	final = 実行時不変, const = コンパイル時不変（定数）
const をつけ忘れていないか	Dart
基本的に var を使用しない	Dart	可読性・保守性が低下してしまうためスコープが狭く今後も広くなりづらい場合や、final で書くことによって記述量が増えてしまい可読性が低下する場合は使用してもいいかもしれないただし、そのような場合はほとんどない
プロパティ、メソッドのスコープは可能な限り狭めているか	Dart	スコープは小さくすると安全性が高まって良い
ロギングを使い分けているか	Dart	目的によるが、print() では不十分な場合がある ref: https://rizumita.medium.com/logging-in-dart-dd9c01eb459a
immutable プログラミングを行えているか	Dart	ref: https://medium.com/flutter-jp/immutable-d23bae5c29f8
使用していない、関数の引数は (_) となっているか	Dart
条件分岐を複雑化していないか	Dart	if(条件式) { return … } (早期リターン) などでネストが深くなるのを回避する
getter を適宜活用してるか	Dart	単純に return するだけの場合、わざわざ関数化しない
共通部分は変数に切り出せているか	Dart
enum の条件分岐を if-else でやっていないか	Dart	後から enum に要素が追加される場合、if-else で判定すると修正の必要性に気づけない可能性があるため、 switch - case 使う
マジックナンバーを使用していないか	Dart	意味のある数値を何も説明なく使用しない → 意味のわかる命名で定数を定義して利用するのが良い
Error が発生しないように実装しているか	Dart	ref: https://zenn.dev/iwaku/articles/2020-12-19-iwaku
nullable な変数を適切に利用しているか	Dart	• 通常はコードの変更にも安全に開発できるようにするために、ローカル変数にして型昇格を行ってから利用する • スコープが狭くほとんど変更されない箇所でnullじゃないと確信できるところは、 “!” を使うことを許容する
pubspec.yaml で開発時のみの依存関係かどうかを考慮してパッケージを追加しているか	Dart
コミット粒度が適切か	GitHub	ビルドできる単位で、など
コミット文が適切か	GitHub	Prefix がついていると見やすい「エラー直した」など具体性が低いものは NG
プルリクエストを提出してレビュアーがレビューし始めた後で、force push を使用していないか	GitHub
マージされたブランチは削除するように設定しているか	GitHub	ずっとブランチを残していると、ブランチを切り替える際に徐々にコストがかかるようになってしまう
README.md を充実させているか	GitHub	アーキテクチャグラフや環境構築の手順が記載されているか
レビュー後に UI が変更された場合、PR 添付の画像も変更されているかどうか	GitHub
自動生成ファイルのコミット状況に応じて README や CI が適切に設定されているか	GitHub	.freezed.dart・.g.dart 等
インデントが揃っているか	IDE
End of File が設定されているか	IDE
Typo を防ぐ仕組みがあるか	IDE	VS Code では、settings.json に Code Spell Checker の設定を行う
保守性	品質
安全性	品質
可読性	品質
一貫したルールに沿っているか	アーキテクチャ