6 ms·

"Smalltalk Best Practice Patterns" was a good book

mpweiher 7y ago
s/was/is/g One of the biggest insights I gained was reading about "intention revealing selector". Before that I had thought that we needed "higher level" programming languages, whatever that meant, exactly. This made me realise the importance of naming (one of the two, three? hard things I computer science). If I could find an intention-revealing selector, I didn't need any higher level, because the current level was just fine. This was the case much more often that I would have thought, it just required work. (eek) And it also gave you an indicator that you might, in fact, need a "higher" language level, or more accurately an architecturally more appropriate one: when you can't create intention-revealing selectors.
- 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.

s/was/is/g One of the biggest insights I gained was reading about "intention revealing selector". Before that I had thought that we needed "higher level" programming languages, whatever that meant, exactly. This made me realise the importance of naming (one of the two, three? hard things I computer science). If I could find an intention-revealing selector, I didn't need any higher level, because the current level was just fine. This was the case much more often that I would have thought, it just required work. (eek) And it also gave you an indicator that you might, in fact, need a "higher" language level, or more accurately an architecturally more appropriate one: when you can't create intention-revealing selectors.

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.