条件を伝える
is・has・canで考える、真偽値の名前
状態・有無・操作の可否を区別し、trueの意味が伝わる真偽値を付けるための実例。二重否定や、状態と権限の混同を避ける考え方を紹介します。
「注文がキャンセル可能か」と「注文がキャンセル済みか」は、どちらもtrue・falseで表せます。しかし同じcancelという名前では、値の意味を読み分けられません。真偽値の名前は、trueになったときに何が成り立つかを一文にするところから考えます。
trueの意味を、まず日本語で決める
最初に「何について」「どの状態ならtrueか」を書きます。「有効フラグ」だけでは、アカウントが利用可能なのか、画面の入力欄が操作可能なのか判断できません。「このアカウントは利用が許可されている」のように、対象と条件を具体化します。
名前と一緒にfalseの意味も確かめます。未確認と不成立を同じfalseにすると、データをまだ読み込んでいない状態と、確認した結果のfalseを区別できません。三つ以上の状態が必要なら、名前の工夫だけで解決せず、状態を表す文字列なども検討します。
状態・有無・可否で候補を分ける
このガイドでは、isを状態、hasを有無、canを操作の可否を考える出発点として使います。これは命名を検討するための目安で、言語が強制する規則ではありません。接頭辞が付いていても、実際の条件に合っていなければ伝わる名前にはなりません。
| 表したいこと | 名前の案 | trueの意味 |
|---|---|---|
| 現在の状態 | isOrderCancelled | 注文はすでにキャンセルされている |
| 関連情報の有無 | hasShippingAddress | 配送先の情報がある |
| 操作の可否 | canCancelOrder | 定めた条件のもとでキャンセルできる |
状態と権限を混ぜない
未発送だからキャンセルできる、とは限りません。支払いの状態や操作する人の権限も関係するかもしれません。canCancelOrderが何を確認した結果なのかを決めておくと、表示条件の抜けを見つけやすくなります。
以下は、未発送かつ操作権限がある場合だけ許可する単純化した例です。実際のサービスでは業務ルールに合わせて条件を定めます。また、画面のボタン表示を制御する真偽値だけを、サーバー側の権限確認の代わりにしないでください。
// 説明用の条件例。実際の業務ルールに合わせて判断する
const canCancelOrder =
!isOrderShipped && hasCancellationPermission;否定が重なる名前を見直す
isNotDisabledのような名前は、それを否定する条件を書くと読み解く負担が増えます。肯定形のisEnabledに置き換えられるか、実際に使うif文まで書いて比べます。ただし既存のAPIがdisabledを受け取る場合は、その仕様に合わせた方が自然です。
CodePartnerへ入力するなら「キャンセル」だけでなく、「注文をキャンセルできるか」のように問いの形で目的を伝えます。生成された候補についても、キャンセル済みの状態を示す名前になっていないかを自分で確認します。
- trueの意味を、チームの別の人も同じように説明できるか
- 状態・有無・権限・業務条件を混同していないか
- 未確認という第三の状態が必要ではないか
- if文で使ったときに否定が重なっていないか
参照資料
TypeScript Handbook — Everyday Types
booleanや、複数の値を区別する型の基礎を確認できます。is・has・canの使い分けは本ガイドの命名案です。
CodePartnerの活用を考える
サービスの内容や利用前の確認事項は、使い方・活用ガイドで詳しく紹介しています。
CodePartnerの使い方・活用ガイドあわせて読みたいガイド
camelCase・snake_case・PascalCaseの使い分け
変数・関数・型の名前をどう書き分けるか。同じ意味の比較例から、既存コードや外部APIに合わせて命名形式を選ぶ手順を説明します。
日時・件数・一覧の名前で、意味と単位を伝える
createdAt、orderCount、ordersは何を伝える名前か。日付と日時、秒とミリ秒、件数と配列を区別する命名例と確認手順を説明します。
IT英語と変数名の読み方を、チームで共有する方法
IT用語や長い変数名を声に出して説明するときの手順。単語への分解、略語の確認、読みと意味の区別、表記を残す用語メモの作り方を紹介します。