0

According to Should interface names begin with an "I" prefix?, I should not add prefix "I" to interfaces. However, I think prefix "I" in interface may be useful sometimes. For example, if the interface have totally different names with the implementation naturally, eg: "Fruit", "Apple","Orange", then I agree it doesn't need to have prefix. But sometimes, it is unavoidable to have a interface having similar name to the implementation, for example, in a game : Tool:

public interface Tool{
}

public class ConsumableTool implements Tool{
}


public class NonConsumableTool implements Tool{
}

I found it would be harder to find the codes that use "Tool" only instead of "ConsumableTool" (eg: search "Tool " to find the places that use Tool as parameter and something like :Tool t=...), because when searching the keyword "Tool", both the place that uses "Tool" and "ConsumableTool" would be listed, which sometimes I may just interested in finding "Tool" only. So I think

public interface ITool{
}

may help me to find the interface among the ".java" easier when I want to find which places use the interface only("ITool") instead of the implementation.

Also when feel tried after reading many lines of codes for fixing bugs, I may yo-yo to "Tool" (move into the Tool.java to view the code) to find implementation to fix bugs wrongly because of forgetting "Tool" is an interface only. Yo-yo to wrong place may be not a big problem, but adding prefix "I" may reminds me "implementations are not at here", reducing the chance of "yo-yo" to the interface accidentally, hence saving me a lot of time.

Code is usually being read more than modified, right? While whether knowing it is interface may be redundant to "Users", it helps developers to read and understand the code faster.

So my question is, are the reasons above rationale to add prefix "I" on interfaces?

wcminipgasker2023
  • 2,993

4 Answers4

5

Adding the I or not is a trade-off between the arguments you mentioned and the things already said in the top answer of the question which you linked to (which, by the way, does not clearly say "never use this prefix in Java"). Note these are all "soft" arguments, no general striking argument why using this prefix (or not) is clearly superior, or makes code an unmaintainable mess.

Hence, it all boils down to what was written in the second highest answer to that post: consistency. This means:

  • When you work alone and have to maintain a program fully on your own, without expecting it to become another team's responsibility, you can use the convention you like most - but once chosen, stick to that convention througout the code base.

  • When you work in a team, do whatever the programming style guide of your team says (and if your team's style guide does not cover this topic, discuss it with them). For Java, it is not unlikely the style guide will recommend against using the I prefix (for C#, it is not unlikely the style guide will recommend it).

Doc Brown
  • 218,378
1

No, IDEs have tools for this, and you will confuse as many people as you help.

There is only one good argument for the I prefix and it's that it means you have one less name to invent

Ewan
  • 83,178
1

You bring up several points and considerations, and you've stumbled on being right for the wrong reasons, so I'll elaborate on the individual points.

I found it would be harder to find the codes that use "Tool" only instead of "ConsumableTool", because when searching the keyword "Tool" [..]

This is an XY problem.

This part of the question is rendered moot when you stop using text search to find usages of a particular type, which is something that pretty much every mainstream IDE provides out of the box.

The better solution here is to learn to use your IDE and stop relying on text search. We should not be deciding the names for our types based on whether or not it meshes well with text search operations.

Also when feel tried after reading many lines of codes for fixing bugs, I may yo-yo to "Tool" to find implementation

Even after several re-reads, I have no idea what you mean by "yo-yo", so I can't answer this part.

but adding prefix "I" may reminds me "implementations are not at here"

This relates back to learning to use your IDE and how to drill down into the code hierarchy. If you use the tools that your IDE provides, the problem gets solved a different (and more effective) way.

Code is usually being read more than modified, right?

Correct, and it's also correct that most naming rules favor the reader's experience instead of the writer's experience. That being said, the reader's experience does not include text search operations.

While whether knowing it is interface may be redundant to "Users", it helps developers to read and understand the code faster.

Unless you are using "users" differently, users should not be seeing your code in the first place. Developers, by definition, are the people who see the code (including the names for the types in question).

So my question is, are the reasons above rationale to add prefix "I" on interfaces?

You're pointing at the right things for the wrong reasons. Yes, I favor using the I prefix for interfaces to help separate interfaces from concrete types; but not for the reasons you listed above.

Actual reasons include:

  • It enables easy confirmation that an injected dependency is mockable without needing to resort to inheritance.
  • When dealing with DI, you will very frequently find that there's only one real implementation of a given interface. It would be bad for readability if you had to come up with two different names just because you have both an interface and a class to represent one thing. It would be significantly better if you could just reuse the same name (foo) in both cases, which is possible when you resort to using the I prefix for the interface (IFoo) and not the class (Foo).
  • While this might not matter for Java specifically, the reasons for using the T prefix for generic parameters are very similar: it helps a reader to quickly separate the prefixed item (interface types, generic types) from concrete types.
Flater
  • 58,824
-1

Depends on your environment. This here looks like you have a class “Tool” and an interface for the class. Tool classes implement that interface and nothing else, so the name of the interface must relate to “Tool”.

In Swift, for example, you use protocols quite heavily to describe just aspects of a class. For example, you want to put instances into a set or use them as dictionary keys: You implement the “Hashable” protocol. You want to print an instance, you implement the “Printable” protocol. And so on. You wouldn’t have an “ITool” protocol, you would think about what you want a tool to do and name a protocol to indicate what it does. Saying “I want an interface for things that are tools” seems pointless.

gnasher729
  • 49,096