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
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
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
CategoryNaming CategoryCodingIssues