5 ms·

If anyone else was wondering: http://wiki.c2.com/?IntentionRevealingSelector http://wiki.c2.com/?IntentionRevealingSelector > Name methods after what the metho

by dflock 7y ago

If anyone else was wondering: http://wiki.c2.com/?IntentionRevealingSelector http://wiki.c2.com/?IntentionRevealingSelector > Name methods after what the method does, don't name methods after how it works.

neilv 7y ago
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 (or, you could say, some of the how becomes part of the what).
- mpweiher 7y ago
  What vs. how was what made this click for me. 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.
  - galaxyLogic 7y ago
    Yes, it packages a set of code-lines together which have the shared property that they all serve the same purpose. Even if it is called from only one location it makes sense EVEN THOUGH IT DOES NOT REDUCE the code-size. It does the opposite if you call it only once. But it makes it easier to understand the code because it hides details under a separate method. It makes it easier to read the calling code because it makes the calling code shorter. I'm not quite sure however if this was the reasoning behind Intention Revealing Selector which I thought was more about how to name methods, not about whether and when to package multiple method-calls into a single new method.

by dflock 7y ago

neilv 7y ago

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 (or, you could say, some of the how becomes part of the what).

mpweiher 7y ago
What vs. how was what made this click for me. 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.
- galaxyLogic 7y ago
  Yes, it packages a set of code-lines together which have the shared property that they all serve the same purpose. Even if it is called from only one location it makes sense EVEN THOUGH IT DOES NOT REDUCE the code-size. It does the opposite if you call it only once. But it makes it easier to understand the code because it hides details under a separate method. It makes it easier to read the calling code because it makes the calling code shorter. I'm not quite sure however if this was the reasoning behind Intention Revealing Selector which I thought was more about how to name methods, not about whether and when to package multiple method-calls into a single new method.