A Few Words About Naming – Methods (In Progress)

Table of Contents

Note: This article is a work in progress!

Maybe the topic seems trivial and worn-out, as everyone knows that you need to create clear, unambiguous names. However, it’s still a greatly neglected area. Teams are still far from understanding that the most depends on naming. No refactoring has as much power as changing a name. It is primarily the names, if used correctly, that form what is called self-documenting code, creating a clear language in the source code of the system you are building.

The topic is described in “Clean Code”, but not as specifically as I see it, somewhat superficially and from a different perspective.

Anatomy of a Method (Function)

Today, a few words about the anatomy of a method (function). Every method has a so-called signature, which includes the name, parameters, and return type, the key components from the viewpoint of refactoring, because readability consists of all three elements – not just the name.

Moreover, it can be said that there are two types of methods:

  • Methods returning a result;
  • Methods not returning a result.

Methods Returning a Result

Note: The following rules do not apply to fluent interface types.

double computeSomeResult(int parameter1, double parameter2, int parameter3 )
  • The method name must always specify clearly and unambiguously what the method does and indicate what its result will be.
  • Always create the method signature in the context of the class it is in (do not repeat the class name in the method name).
  • Therefore, methods returning information about errors that occurred during its execution are an anti-pattern (though there is a trace number of cases when this strategy might be justified – usually when working with legacy code); many frameworks suffer from this “disease”.
  • It is highly penalized to treat input parameters as a way to return a result, which most often happens in the case described in the point above.
  • The method parameters co-create meaning with the name – they must complement it and be consistent with it.

Examples and Comments

List<Content> retrieveChildren(Content parentContent)

Okay! The name suggests that the children of the parameter will be searched for, and that’s the return type as well. More fluent versions (TBD to explain what this is):

List<Content> retrieveChildrenOf(Content parentContent)
List<Content> childrenOf(Content parentContent)

Or, if it were appropriate to the context, the method childrenOf could be part of the Content class, and then its signature would be:

class Content {
   List<Content> retrieveChildren() // ..
   // or more fluently
   List<Content> children() // ..
}
interface ContentProcessorResolver {
   //…
   /* @return returns a list of content tailored to the resolver */
   public List<? extends Content> resolve(Content content);
   //…
}

Bad name – it would suggest (in the context of the interface it’s in) that the result would be an object of the ContentProcessor class.

TBC…

(Text translated and moved from original old blog automatically by AI. May contain inaccuracies.)

Related Posts

Technical Leader Worries: I Am Not a Born Leader

Technical Leader Worries: I Am Not a Born Leader

Have you ever heard about Alexander the Great, Napoleon, J. F. Kennedy, Martin Luther King? I bet you have. These are great historical leaders. These names often come to mind when we think about leadership. When coupled with Hollywood movie characters, we imagine leaders as heroes with strong charisma and exceptional talent for public speaking. This stereotype is hard to shake. But wait a minute… Is this what we should adhere to when talking about technical leaders?

Read More

Natural Course of Refactoring online on InfoQ

I am so delighted that the article about Natural Course of Refactoring is live. It is a very simple, yet powerful idea about refactoring (but not easy after all) and I hope this way it will reach more people than ever before. So please retweet it and share it wherever you can.

Read More

Don't Be Fooled by What Others Say...

Don’t Be Fooled by What Others Say…

A few days ago, as a conscientious citizen concerned about my health, I decided to have some preventive tests to determine my current health status. Initially, I chose a doctor funded by the NFZ (National Health Fund), as I wanted to maximize the value of the 250 PLN the state collects for my healthcare (I won’t delve into discussions on the efficiency of fund management in state institutions). Of course, I had done some research on which tests might make sense at my age, printed a list of potential tests, and presented it to my doctor.

Read More