もうBooleanはIsでいいんじゃないか?というお話

前提

システムに携わる人全般向け。

お決まりの話

新規のプロジェクトに携わると、必ずコーディングの意識合わせの話になる。それが形となってコーディング規約となるわけだが。。SetGetといったお決まりのアクセサーはいい。オブジェクト指向がしっかり根付いたこともあって、言われなくても意識合わせができている。それでも、たまにRetuenのないGetterや、ReturnのあるSetterを見かけることもあるが。まぁ、これはコーダーが悪いわけではなく、設計のレビューか製造のレビューフェーズでつぶされていてしかるべき。

で、だ。これもまたお決まりで、Booleanは?という話になる。そして出てくるのが、canは許容するだのhasもあるだの、めったに見ない例をあげての話し合いだ。ほんとに、そんな動詞くっつけた組み込みメソッドなんて見たことあるんだろうか?と不思議になる。自分が使用した中では、.netのFileUploadがもっているHasFile(s)くらいのものだ。canなんて見たことがない。それってその現場特有のローカルルールを、声のでかい誰かが節操なく垂れ流しただけなんじゃないのって思ってしまう。なぜそんな話になるのかというと、Booleanを返すベンダー提供ライブラリメソッド名の大多数がIsで始まるからだ。おそらく、自作するにしても「Isしか使ったことがない」という人が大多数を占めるんじゃなだろうか?

SetterGetterのように、ルールは単純化されているほうが圧倒的に可読性が高いのは間違いない。

まとめ

設計フェーズはあまり好きではない。とにかく退屈だ。

20~30半ばくらいまではわからないことだらけで楽しかったのだが、以降は同じことを繰り返しているだけのような気がする。製造になると、プロジェクトが異なると全く違った思想に触れることも多いので、モチベーションの維持が容易だ。テストもまぁ、最近はコードを書くのでそれなりに楽しめる。

やっぱり設計は面白くない。。そのうえ、もう何度目になるかわからないBooleanの話を聞くと、「またか」とやる気バロメータが一気に下降する。

なので、もうIsでいいよ、と愚痴りたくなった。。

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です