Using Good Naming To Detect Bad Code

If you use MeaningfulNames, you might experience some methods or variables getting awfully long names. Often these names include prepositions like "from", "to", "with". Names like this can be used as an indication that the method or variable might benefit from being moved to another class, where its name would be shorter.

Stab at rule: Keep methods in the classes that makes their names simplest.

-- JohannesBrodwall

Well done. Good boy -- doggie bisquit! (in keeping with the tone of the rest of this page)

---

Q: Can you give some examples of the sort of BadVariableNames and BadMethodNames? you're talking about? I'm not able to imagine any with "from", "to" or "with" in them... Maybe this means I've already internalized this rule :-) -- AlanFrancis

A: According to this rule:

• bad: Updates.applyTo (Account account)
• good: Account.apply (Updates updates)

---

I have only experienced this problem on large systems where the rate of change is low, and changing other classes than the one you're currently working on is discouraged. I found it necessary to invent method names along the lines of "getAddressesFromMessage". This method only accesses the variables in the "Message" argument, none in the "this" object. The reason I had to do this was that changing the Message class at this point was out of the question.

Names like these expose underlying CodeSmells, in this case FeatureEnvy. If you have a strict naming policy, smells might thus be easier to spot at a glance.

Does this help? -- JohannesBrodwall

I agree with the quip on strict naming policy. I am a member of a group of three: style is tight. When a class is misplaced or a name ill contrived it becomes quickly apparent that something is wrong.

---

Another rule: Names that require "And" or "Or" usually indicate a method that should be split. For example:

   myDog.RollOverAndPlayDead();

would probably be better as:

   myDog.RollOver();
   myDog.PlayDead();

A more common example might be a call that should be named:

   /*
   ** Pass in buffer pointer to get data
   ** Pass in NULL pointer to get size for buffer
   */
   FillInDataValuesOrReturnSizeOfBuffer();

would be better as:

   SizeOfDataValues();
   DataValues();

What about the circumstances where the two methods are called together several times? I usually refactor those by creating a new method with the name combining the names of both methods with And or Or and then use ComposeMethod. Now I can replace two lines with one. -- ChaoKuoLin

Well, then we're back to

    myDog.RollOverAndPlayDead();

when we don't want to lump those two actions together.

If those two actions are always called together and are logically one action from the point of view of the caller then perhaps we need a new name for it like:

    myDog.performTrick();

and

class Dog {

    void performTrick() {
        this.rollOver();
        this.playDead();
    }

}

{Wouldn't YagNi dictate RollOverAndPlayDead unless sub-division is likely to be needed? (Or if a method is excessively long). One shouldn't partition without a relatively strong reason.}

---

Wouldn't a better refactoring pass a Trick token to PerformTrick() to allow for new tricks to be taught?

Easily enough deferred until we start adding new tricks. Just don't let the Dog get old.

{It may be presumptuous to assume "tricks" and "dog actions" are different things. Fetching the paper (or iPad these days) may start out a "trick" but turn into a regular activity. We don't want a generic "do" method, that's usually silly. I'm hesitant to endorse a code design rule that says "Always do X" such as "always split AND titles into two+ methods/classes/things". Consider X, fine, but also consider YagNi and A and B and C and D, etc.}

---

CategoryNaming