Interface declaration rules. "I" or "!I"?

Question

Java

Hello.
Who can adequately explain why it is worth declaring interfaces with the letter "I":

interface IDisposable
{
}

Or why you shouldn't do it:

interface Disposable {
}

I'm a .NET Developer, and by chance, in the Java team, looking at their code, I said: "OMG, how can I declare an interface without the letter `I`?". After that, taking advantage of the numerical advantage, they successfully mixed me with shit ... =*(
So, how is it still more correct? And it is advisable not to be based on your preferences, but to justify somehow.
Thanks in advance.

Answer 1

There is no "official" strict convention on this matter. As RGV has already pointed out , which convention to use is a personal matter for the team/company/tech director.
I myself once came to Java from Pascal and .NET, and I also adhere to the notation with I, because this allows you to visually distinguish the interface from the class in the code. Just for example:

...
  IProducer simpleProducer = new Producer();
  IProducer sofisticatedProducer = new SpecialProducer();
...
  public void produceSomething(IProducer producer);

When looking at such code, it is immediately clear which one is from xy, without any additional clicks, hovering over and other dancing with the IDE.
And although this does not explicitly prevent the creative dunce from sticking a class where you need to use the interface, it will help the conductive reviewer to notice the rake with the naked eye :) From my point of view, the price of such convenience is 1 (one!) extra. character in the name is quite justified.

Answer 2

In Java, implements/extends. there I is redundant.

Answer 3

In C#:
1. Microsoft's naming convention for C#, which everyone uses
2. To distinguish from classes
How it's done in Java - Java experts know and I think they have reasons to do what they do (including, I don't know if they are right specifically your javascripts or not), however there is no reason for javascripts to follow the naming conventions from c# and vice versa.

Answer 4

Somehow everything is unconscious... There is a persistent rejection of Java-style, but "why" - not a single thought?! Javers mixed you with shit, too, you see, also without any justification. Let's do it yourself - why do you need this letter yourself? How does she help?

Answer 5

From experience: java does not use elements of Hungarian notation , including the interface name does not have the "I" prefix. When implementing an interface, classes are sometimes given the "Impl" suffix (but not always; most likely only when the only purpose of the class is to implement the interface).
How to justify, I do not know, most likely, it happened historically. There are some general coding conventions from Sun, but they are used as guidelines rather than hard and fast rules. Well, all normal IDEs (at least for java) are able to show the type of any identifier, so it is redundant to indicate this in the name.

Answer 6

It's just a coding style. The ideology that the team adheres to. No more.

Answer 7

In our team, the prefix "I" is not used. Everyone is right in saying that this agreement has pluses and minuses and is generally a matter of personal taste. There are many very good projects where I is used and where I is not used. The main thing is that it does not turn into a religion. If you are being treated like crap at work, consider whether you need such a job :-)

Answer 8

1. Valid to distinguish an interface from a class. Since classes are often named in this way.
   List-IList
2. when typing is convenient. "I" + Ctrl + space
3. Readable. Including just contextually corresponds in most cases. IHasGenerator - I Have a Generator

Answer 9

Well, there is a clear difference. For me, for example, the authority of the Java api. And there prefixes are not used.
Yes, and I myself believe that visually distinguishing interfaces from classes in java makes no sense and is even harmful. Sometimes, of course, I call *Impl names, but this is from laziness. The title should clearly describe the implementation.