Intention Revealing Selector

One of the SmalltalkBestPracticePatterns. (Quick note for non-Smalltalkers: "selector" means "method name").

Name methods after what the method does, don't name methods after how it works.

Examples are given in IntentionRevealingNames since the concept applies in any language.

I think the pattern name is a misnomer. The pattern, as given above, is good. But "what the method does" is not necessarily its "intent", but its "essence" (for a lack of better word). The what must not be confused with the why.

Nor should the why complicate understanding of operations within the method. The why can often be transient or abstract, changing with time or in application.

Perhaps such things as overriding and overloading can be useful in illustrating the difference.

---

Name services after what they do, and postpone the why until the point of usage

• IdentifiersRevealIntent

---

Name methods after what the method does (or better yet, why you want whatever it does done), don't name methods after how it works

• IntentionRevealingNames

---

The most important thing about any (without loss of generality) method is what it accomplishes or why one would call it, not how it does whatever it does

• IntentionNotAlgorithm.

---

CategoryNaming CategoryCodingIssues