3.5. Consistency Is Simplicity

 <  Day Day Up  >  

Consistency is a form of simplicity. Consistency makes it easy to deal with the world. Can you imagine using your cell phone if every time you turned it on, another revision of the user interface was downloaded to it? However, too much consistency can inhibit creativity. You should apply consistency with a purpose. "A foolish consistency is the hobgoblin of little minds" (Ralph Waldo Emerson).

Consistency is not just following code style conventions. [*] It is doing similar things in a similar manner, unless there is a good reason to change. If you are going to use exceptions, come up with guidelines for what types of events are exceptions and what types are not. For example, should the failure to find a customer with a particular name be an exception or an expected condition? Is it the caller's or the callee's responsibility to check contracts? Will a dozen callers contain the same checking code that could be stored once only, in a single callee?

[*] Gary K. Evans, a reviewer, tells programmers on his projects that the best they can do is to make their intent, or interface, intuitively obvious. The second-best thing they can do is to make it consistent, so once Evans learns it, at least it has consistency.

The development environment can provide consistency. For example, Borland JBuilder has a command that creates a listener for events. A separate listening class is created for each event, along with a separate method that is used to code the response to the event. This approach adds a level of indirection. However, once you're familiar with the approach, it is easy to determine which methods are event handlers.

CONSISTENCY IS SIMPLICITY

A consistent approach to style and solutions can make code easier to maintain. [*]


[*] See Kernighan and Plauger's The Elements of Programming Style for an original discussion on this topic. One reviewer noted, "Uniform rules are invariably simpler."

CONSISTENT FOR WHOM?

I worked with a group of programmers who programmed the menus in the ordering stations for a fast food chain. Being curious as to how the end user viewed the ordering process, I stopped at one of the franchises and queried the server. I asked how she liked the system. She said it worked fine until they introduced new menu items. Then she messed up orders for a few days. I asked why that happened . She said that she got used to the placement of the order items and would enter the order practically without looking. When a new menu item was introduced, the programmers rearranged the interface to put the item in its appropriate place. The programmers thought they were being consistent, but the consistency to the server was that the positions of the old items remain unchanged.


 <  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