Uncommunicative Name


Uncommunicative Name

Symptoms

A name doesn't communicate its intent well enough.

  • One- or two-character names

  • Names with vowels omitted

  • Numbered variables (e.g., pane1 , pane2 , and so on)

  • Odd abbreviations

  • Misleading names

Causes

When you first implement something, you have to name things somehow. You give the best name you can think of at the time and move on. Later, you may have an insight that lets you pick a better name.

What to Do

  • Use Rename Method (or field, constant, etc.) to give it a better name.

Payoff

Improves communication.

Contraindications

Some teams use i/j/k for loop indexes or c for characters ; these aren't too confusing if the scope is reasonably short. Similarly, you may occasionally find that numbered variables communicate better.

Exercise 9 Names.

Classify these names as embedded type, uncommunicative, or OK.

___ addItem(item)

___ doIt()

___ getNodesArrayList()

___ getData()

___ makeIt()

___ multiplyIntInt(int1, int2)

___ processItem()

___ sort ()

___ spin()

See Appendix A for solutions.



Inconsistent Names

Symptoms

  • One name is used in one place, and a different name is used for the same thing somewhere else. For example, you might see add() , store() , put() , and place() for the same basic feature.

Causes

Different people may create the classes at different times. (People may forget to explore the existing classes before adding more.) Occasionally, you'll find people doing this intentionally (but misguidedly) so they can distinguish the names.

What to Do

Pick the best name, and use Rename Method (or field, constant, etc.) to give the same name to the same things. Once you've done this, you may find that some classes appear to be more similar than they did before. Look for a duplication smell and eliminate it.

Payoff

Improve communication. May expose duplication.

Notes

The Eiffel language uses a common pool of words for the names of its library features. You can use this technique as inspiration: Look to existing library names for the vocabulary you use.

Exercise 10 Critique the Names.

Which name would you expect to use?

  1. To empty a window (onscreen)

    clear()

    wash()

    erase()

    deleteAll()

  2. For a stack

    add()

    insert()

    push()

    addToFront()

  3. For an editor (to get rid of the selected text)

    cut()

    delete()

    clear()

    erase()

  4. As part of a file comparison program

    line1.compare(line2)

    line1.equals(line2)

    line1.identicalTo(line2)

    line1.matches(line2)

See Appendix A for solutions.

Exercise 11 XmlEditor.

You have a class XmlEditor. You want to introduce a parent class.

  1. What do you call it?

  2. You want to introduce an interface that the parent will implement. What's a good name?

See Appendix A for solutions.



Chapter 5. Unnecessary Complexity

"You aren't gonna need it." “Ron Jeffries


Code is sometimes more complicated than it has to be to solve the problem at hand. There are two causes for this problem:

  • Sometimes code gets complicated for historical reasons (e.g., there can be code rot ” the leftovers from old ways of doing things), but it no longer needs the complexity.

  • Another cause of complexity is the practice of overgeneralizing the design. This is often in anticipation of future requirements, or premature performance tuning.

Remove these problems when you run into them. You'll often find that this can lead to further insight and simplification.