Prefactoring

6.7. Extreme Naming

In a previous section, you might have noticed an example of an extremely long method name:

    class FileWithLines
        String read_line_up_to_new_line_and_toss_new_line( )

Suppose the method name was read_line. If I use read_line a lot, I might recall that it either does include or does not include the newline character. If the method is specifically named or has a parameter which denotes its operation (e.g., read_line(TOSS_NEW_LINE)), it is easier to remember the method's purpose.

Now you are probably saying: "this is extreme naming." You are right. If your group uses a method or variable often, a short name can be remembered more easily. However, if a method is rarely used, a long name is often better. The reader will not be scrambling for the documentation to recall what the method actually does.

COMPREHENDING DAVID COPPERFIELD When I was in elementary school, I attempted to read Charles Dickens' David Copperfield. The book contained many words that were not in my vocabulary at the time. I read the book with a dictionary by my side. Every time I encountered an unfamiliar word, I looked it up in the dictionary. Needless to say, this cross-referencing destroyed the flow of the plot. If Dickens had written the book using familiar words, it might not have been a literary classic. However, it would have been more understandable. Likewise, it is easier to read code that has methods with names that do not need to be cross-referenced.