CODEWITHSUNDEEP
javanaming-conventionsmethod-names
Darkoboar
Darkoboar

Reputation: 195

one-parameter method naming: repeat paramter in method name

sometimes we need to create simple method with just one parameter. For example:

private boolean isMockedPlayer(Player player) {
    return player == Player.MOCKED;
}

So, my question is: wouldn't it be better to name method: isMocked(Player player) and not repeate word "Player" so many times? Any official guidance? I realize that such repeat is essential for setters, but not sure for other cases like above.

Edited: Well, an example probably wasn't the best. But the question is not about this code snippet, but about general principle - should we repeat parameter type in method name or not?

Upvotes: 2

Views: 305

Answers (2)

Vivin Paliath
Vivin Paliath

Reputation: 95498

Why not have it on the Player instance itself?

public boolean isMocked() {
    return this == Player.MOCKED;
}

player.isMocked() seems more natural than someOtherService.isMockedPlayer(player).

It does kind of defeat the purpose though if Player is an enum, because then MOCKED is public.

On the other hand, if Player is an actual class and if MOCKED is an internal static instance that you maintain, then you can implement isMocked() as above and you won't even have to expose MOCKED to the outside world.

but about general principle - should we repeat parameter type in method name or not?

Well, it depends. Choose a naming convention that is at the very least:

  • natural
  • not surprising
  • not confusing
  • as succinct as possible

You want to clearly convey the context and meaning of the operation that you are performing.

I think your example itself is kind of redundant because you're checking the state of an instance. So in this scenario, it makes more sense for the method to be part of the instance itself. But a better example is perhaps a method on an class that accepts a parameter that is the same type as the class itself. For example:

public void merge(BinarySearchTree tree) {
    ...
}

In this case there is no need to call the method mergeBinarySearchTree; bst.mergeBinarySearchTree(other) doesn't convey any more information than bst.merge(other). But even then, you can't use this as a hard and fast rule. Perhaps your object has many different kinds of merge operations that all accept different things. In that case it might make sense to have the method include the name of the thing being merged in... but that could also depend on how you have designed your object model.

tl; dr It depends; but in general, choose a name that conveys accurate information about the semantics and context of the operation without being needlessly redundant or verbose.

Upvotes: 2

aro_tech
aro_tech

Reputation: 1143

I think you're having trouble naming this method because it doesn't do anything useful. It just does a comparison which requires barely more code than the method call. It might be useful to add an isMocked() method to the Player enum itself. There's not a big difference between "player == MOCKED" and "player.isMocked()", but if there were several types of mocked players, it would be useful.

BTW, I think there may be a design problem if you have to check whether an object is mocked or not. The idea of a mock is to take the place of a real object to verify the interactions. If you modify the interactions when it's a mock, what are you verifying?

Upvotes: 0

Related Questions