Earlier quoted context omitted.
If anyone else was wondering: http://wiki.c2.com/?IntentionRevealingSelector > Name methods after what the method does, don't name methods after how it works.
This rule applies even more to API documentation. As soon as you mention how , that becomes part of the what interface you have to support. With internal method names, for tricky code, it's a bit more fuzzy, and sometimes I've found that putting how information into the name seems to be a great idea, for readability&correctness of code that calls it. This is more for functions/methods for which the how is relevant (o…
Apparently, there was a method to invert the screen
>>>flashScreen
self invertScreen.
self delay:sometime.
self invertScreen.
There was also the requirement to have a "visual beep" to accompany an acoustic beep. The way the visual beep was to be implemented was to invert the screen.Now you could have just put "... invertScreen." where you were supposed to do the visual beep.
Or you could add a method:
>>>visualBeep
self flashScreen.
Before, I would have said this method is completely superfluous, after all it doesn't really do anything that isn't already in the system. However, the service it provides is giving something the correct name. This is highly valuable.