命名則のお話

開発

　http://szne.sakura.ne.jp/index.html#2006717

enumの中の名前も気になるところだけど、これはフラグだからこれでもまあいい。許容範囲。問題なのはFLAG_CHECK。あかん、あかんて。CHECKはあかん…。いわゆるアンチパターン（やってはいけないパターン）

「フラグが立っているかif文でチェックする」という文脈で使うのなら、FLAGEDとかIS_FLAG_ONとかにすべきです。if(FLAGED(status，POISN) )とか、if(IS_FLAG_ON(status，POISN) )と書いてあれば、英語的にも意味が明らかで間違いようがありません。

たとえば、statusは必ず一回チェックする必要があって、「チェックが既に行われたかどうか」を調べる、という文脈で使われるのならば、FLAG_CHECKでもギリギリ許容範囲です。(でも、普通はFLAG_CHECKEDとかIS_FLAG_CHECKEDにすると思います)

　そこにツッコミが入るとは思いませんでした。
　実ソースは拙いと思ってC/C++ソースを適当に改変して乗せたのがよくなかったですね。

　enumのフラグ名も実際は「POISON」単体ではなく「XXXX_FLAG_POISON」だったりします。

　とりあえず、実際にはそれがフラグなのか何なのか、フラグだとしたら何のフラグなのか、は命名則で解るようにしてあります。
　FLAG_CHECKも、実ソースはif( IS_FLAG_ON( status, XXXX_FLAG_POISON ) )に御座います。
　言われる通りFLAG_CHECKであると「フラグをチェックしたか否か」という文脈にとられかねないですね。また、その場合にも英文法で言えば「チェックしたか＝CHECKED」が正しいのは言われる通りであり、FLAG_CHECKという命名は大変不適切であるとはおっしゃる通りに御座います。

　まぁ、以前メインプログラマが英単語を間違えていて、後から#defineでかわしたなんてことがありましたけども。
　某社のライブラリは「英文法の統一化」やらなにやらで関数やマクロの命名則がよく変わって「互換性のために」の名目で同意にするための大量の#defineが記述されたりしていました。
　開発環境もベータだったので、なんでしょうけど。
　#defineで無理矢理通さなくても一括置換するから、置換命名対応表とかの方が良いのになぁ、と思ったりしたこともあります。

　色んな意味で命名則は大事だと思っております。