フラグ項目の物理名は「is」で付けるべき
ユーザ情報が入ってるテーブルに、「そのレコードを更新していいタイミングかどうか」を表現するためのフラグとして「IS_UPDATABLE」という物理名を書いたら、レビュー時に英語ができない上司に「更新のフラグなんだから『UPDATE_FLG』だろ、他の既存項目も『○○_FLG』だし」と言われ、以下のようなメリット込みで説明したが、遠回しに「私が理解できないことは間違いだ、お前の話は聞く気がない」というようなことを言われたときの話。
「○○_FLG」という項目名は状態が分からない
「更新フラグだから UPDATE_FLG」なんていう、単語を直訳したものをそのまま並べたネーミングだと、あとから見た時に「このフラグが True な時って、『更新していい』んだっけ？それとも『更新したらダメ』なんだっけ？」と分からなくなることが多い。
設計書にはどっちがどっちと書いておけばいいのだろう、と言うのかもしれないが、頻繁に設計書を見返さないといけないようなネーミングはいつか誤解を招き、バグに繋がることだろう。
一方、「IS_UPDATABLE」といった名前であれば、「それが True なら更新できるし、False なら更新できないカラムである」ということは項目名だけで一目瞭然だ。
テーブル更新前にプログラム内でデータを操作するような時も、この項目の値を取得しながらif( UserDataDTO.isUpdatable() ) { と自然言語に近い形で条件文が書けるので、直感的で読みやすい。
「IS_○○」という名前が受け入れられない人間の3大原因
単純なことだけどメリットがある命名規則。それを受け入れられない人間には以下のような原因があると考える。
- 英語ができないために「able」を付けて「可能」を表す、ということが理解できない
- プログラミングができないために「『
IS_○○』『CAN_○○』と書けば Boolean 値が取れるモノ」という命名の定石を知らない。設計書もコードも読まないからコーダーにとってのメリットを考えられない - より良くすることよりも、これまでの文化・慣習をなぞることが大事でありそれが絶対だから、より悪いものでもそれがその現場の慣習になっていればそちらを採用する、という保守派であるため
「○○_FLG」という名称が登場するシステムは、必ずといっていいほどこの項目によるバグを引き起こしていると思う。よくよく考えて使おう。