Semantics and Method Names

I am reading Refactoring: Improving the Design of Existing Code right now. In his discussion on method naming on pp. 110-111 he said something that seemed well said. I thought I would share it.

"People sometimes ask me what length I look for in a method. To me length is not the issue. The key is the semantic distance between the method name and the method body. If extracting improves clarity, do it, even if the name is longer than the code you have extracted."

People at work have commented several times on the rather lengthy method names that I sometimes produce. If I have a method that does some logic to modify a widget in a particular way then I might have a method called ModifyTheWidgetInSuchAndSuchAWay(); because, well, that makes the naming of the method clear. Who cares if the name is long. The point, in Fowler’s words, is that the meaning of the method name should express the meaning of the method body well. If there is a large difference between the meaning of the two you either a) have a badly named method or b) your method is doing too much.