6.7. Extreme Naming

 <  Day Day Up  >  

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.


 <  Day Day Up  >  


Prefactoring
Prefactoring: Extreme Abstraction, Extreme Separation, Extreme Readability
ISBN: 0596008740
EAN: 2147483647
Year: 2005
Pages: 175
Authors: Ken Pugh

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net