Corredor

ウェブ、プログラミングの勉強メモ。

フラグ項目の物理名は「is」で付けるべき

ユーザ情報が入ってるテーブルに、「そのレコードを更新していいタイミングかどうか」を表現するためのフラグとして「IS_UPDATABLE」という物理名を書いたら、レビュー時に英語ができない上司に「更新のフラグなんだから『UPDATE_FLG』だろ、他の既存項目も『○○_FLG』だし」と言われ、以下のようなメリット込みで説明したが、遠回しに「上司自身が理解できるものが正しいものだからお前の話は聞く気がない」というようなことを言われて諦めて従ったフリして設計書を修正せずに実装を通したときの話。

(上司は一度レビューしたドキュメントの管理をその後一切しないし、英語ができないから英語が多くなるコードレビューはよく見ずに OK 出しちゃう性質を利用した強硬手段、こういう上司の扱いの話は他所でする)

「○○_FLG」という項目名は状態が分からない

「更新フラグだから UPDATE_FLG」なんていう、英語ができない人間が単語を直訳したものをそのまま並べたネーミングだと、あとから見た時に「このフラグが True な時って、『更新していい』んだっけ?それとも『更新したらダメ』なんだっけ?」と分からなくなることが多い。

設計書にはどっちがどっちと書いておけばいいのだろう、と言うのかもしれないが、頻繁に設計書を見返さないといけないようなネーミングはいつか誤解を招き、バグに繋がることだろう。

一方、「IS_UPDATABLE」といった名前であれば、「それが True なら更新できるし、False なら更新できないカラムである」ということは項目名だけで一目瞭然。逆に取り違える方が悪い、と言える明快なネーミングである。

テーブル更新前にプログラム内でデータを操作するような時も、この項目の値を取得しながらif( UserDataDTO.isUpdatable() ) { といった条件文が書けるため、直感的で読みやすい。

(Java だと getter を挟むことが多いだろうから #getIsUpdatable() とかになるのかもしれないけど、それでもまだ「更新していいのか悪いのか」の判断は項目名だけでできる)

「IS_○○」という名前が受け入れられない人間の3大原因

単純なことだけどメリットがある命名規則。それを受け入れられない人間には以下のような原因があると考える。

  1. 英語ができないために「able」を付けて「可能」を表す、ということが理解できない。
  2. プログラミングができないために「『IS_○○』『CAN_○○』と書けば Boolean 値が取れるモノ」という命名の定石を知らない。設計書もコードも読まないからコーダーにとってのメリットを考えられない。
  3. より良くすることよりも、これまでの文化・慣習をなぞることが大事でありそれが絶対だから、より悪いものでもそれがその現場の慣習になっていればそちらを採用する、というひねくれまがった保守派なため。

個人的には「○○_FLG」というネーミングに疑問を抱かない時点でバカ認定して金輪際会話しないようにするレベル。視野が狭過ぎる人間であることが一瞬で分かるので指標にしている。