レビューで指摘された内容をそのまま放流するシリーズ。
ある Form のクラスに「詳細情報をセットして表示する」メソッドを作成しました。そのメソッドに対して SetDetails のようなメソッド名をつけました。このメソッド名に対してコメントをもらいました。
メソッド名は違う気がします。
ダイアログの振る舞いを表すと考えてShowDetailsとかでいいのではないでしょうか？
何をするかより、何が起きるかを表現できると、ソースコードが読みやすくなりそうです。
私はこの指摘を受けるまでメソッド名に違和感を持っていませんでした。自分で実装すると、ついつい実装に寄り過ぎた命名になってしまう癖があるようです。でもコメントのように何が起きるのかを表現すれば、実装に寄り過ぎた命名になりにくいと思いました。
この指摘は有用な情報だなと思い社内展開したところ下記のようなコメントももらいました。
私と同時期に入社した社員からは
これすごくあるあるですね…
どういう処理をしているのかをメソッド名に書いていて、「処理についてはメソッドの内容読めば分かるよね？」って指摘をもらったこと結構あります
とコメントもらいました。良かった。仲間がいた（笑）
ベテラン勢からは
トップダウン的にメソッド書くと、そうなりにくい気がしないでもない。そういう意味ではTDDとかでも効果はあるかも
とコメントもらいました。なるほどです。上流から考えれば内部実装に寄ることはなく、そのメソッドにしてほしい内容を抽象化して命名できそうな気がします。
そして実際にレビューでコメントをくれた方からは、
よく関数名を変えた後に、その関数の呼び出し箇所を見直します。
かっこよく呼び出せているか考えます。
TDDと似た感じだと思います。
とコメントをもらいました。呼び出し側からの気持ちになって考えると確かにうまくいきそうな気がします。「かっこよく呼び出せているか」という判定をしているあたりが天才味を感じさせるコメントです。
命名は難しいですが、ちょっとした意識の切り替えで命名センスが上がりそうだと感じた指摘でした。