「チェック」って機能名？
ときどき見かけませんか？
- 通信チェック
- DBチェック
- データチェック
などの「○○チェック関数」。
でもこれ、機能名ではありません。ただの振る舞いを表しているだけです。
「チェック」が表しているもの
関数名を読む人は、
- 何をする機能か
- 入力は何か
- 出力はどう使われるのか
を想像します。
ところが「○○チェック関数」と書かれていると、「何かをチェックする」という振る舞いしか伝わりません。目的も結果も見えてこないんです。
特に「データチェック」なんて名前は最悪で、戻り値が true でも false でも、結局何を意味しているのか曖昧になってしまいます。
具体例
「通信チェック関数」を例にしてみましょう。
- 名前からわかるのは「通信を何かチェックするらしい」ということだけ
- でも実際には「接続済みかどうかを判定する」のが目的だったりする
そうであれば hasConnection の方がずっと明確です。
実際のコードに現れる混乱
よくあるパターン：
実行結果 = 通信チェック(引数, &結果);
if (実行結果 == 失敗)
return 失敗;
else
if (結果 == 成功)
データセット(成功);
else
データセット(失敗);
一見すると「通信チェックして結果を返してるんだな」と読めますが…
よく見ると「実行結果」と「結果」の2種類の値を返していて、判定が二重になっています。
つまり読み手はこう混乱するわけです：
戻り値は通信が正常かどうかを表すのかな？
でも「失敗」を見たあと、もう一度「失敗」を判断してるぞ？どういうことだ？バグか？
「○○チェック関数」を好むのはどんな人？（私見）
- 1人で全部作りきった経験がある人
- ロジック優先で考えるタイプの頭の良い人
-「可読性よりスピード！」な現場にいる人
こういう環境では、名前にこだわるより「とにかく書いて回す」方が効率的だからです。
まとめ
関数やクラスに「check」と書こうとしたときは立ち止まって、考えてみましょう。
• それは機能や目的を表している？
• それとも単なる「振る舞いの説明」になってない？
「振る舞いを伝えるだけなら、関数定義を見てもらった方が確実」です。
だからこそ、名前では 機能や目的 を伝えることを意識しましょう。
例外
ただし「チェック」がすでにユビキタス言語化している場合（例：ドメインで「○○チェック」という言葉が共通認識になっている場合）は、そのまま使うべきです。無理に置き換えると逆に混乱します。