Long methods are usually a concatenation of several shorter pieces of code that accomplish something in a blow-by-blow fashion. Sometimes, there are comments […]
> A visitor to an Irish castle asked the groundskeeper the secret of the beautiful lawn. The answer was: *just mow the lawn every third day for one hundred years*.
Roger Whitney comments in college course material that spending a little time frequently is much less work than big concentrated efforts, and that it produces better results in the long run. Therefore, he concludes that it is wise to frequently spend time cleaning up your code. I could not agree more.
Refactoring in this continous and merciless manner is connected with software quality as well. Here are some definitions. […]
Quality is producing things of value to some people. Real quality improvement starts with knowing what your customers want. What is the quality of the programs you are working on, right now?
p. 11: or blank lines in between the pieces as well. These separations are strong hints of where distinctions should have been more explicitly drawn.
The point of separating the pieces and putting them in methods is simply that of distinguishing the parts and applying labels. This allows smaller parts to interact, which leads to behavior networks which are easier to change and improve.
While large sections of at first sight cohesive code may be acceptable when written in a workspace or an inspector where one may want to accomplish a one time goal, they really do not belong in methods because typically one creates classes to manage functionality that will be around for longer than a workspace.
To maximize the benefit of using small methods to implement behavior, the written expression of a method should consist of the following two parts:
1. An external interface definition, consisting of the name of the selector and the internal names of any supplied arguments. Comments may be added if absolutely necessary. 1. A small amount of source code that implements the behavior described by the external interface definition above.
Note the strong contrast between the two.
You could think of the selector as the cell membrane receptor, and the method being the implemented response to the receptor recognizing a message.
The external interface is made known to any potential sender, while the implementation is kept private to the receiver.
This means that a definition consisting of selector pattern and subsequent code sits on both sides of the fence at the same time: the selector sits on the outside of the object, while the method lives inside the object. Note that all of this is left unsaid, and that the accomplished brevity allows for an exquisitely concise way to take advantage of the structure of it all.
The distinction between the two should always be explicitly illustrated by means of an obvious visual cue such as a blank line. In addition, no well-factored method should be interlaced with blank lines or comments since these hint at distinctions which are not being made explicit for everyone to see.
Selectors should be used to clearly reveal the intention behind relatively small methods. When this is done, comments display a strong tendency to become redundant.