Suggestion to remove I prefix from interface names

[mocanu-razvan]

Expected Behavior

The TypeScript guidelines found on their website's page on Writing Declaration Files say:

In general, you shouldn’t prefix interfaces with I (e.g. IColor). Because the concept of an interface in TypeScript is much more broad than in C# or Java, the IFoo naming convention is not broadly useful.

What do you think about adopting this advice?

Current Behavior

There are a lot of interfaces I can see in the library that have their names prefixed with I, e.g. IKernel, IProvider etc.

Possible Solution

Remove the I prefix from all interface names.

Context

I am starting out with this library and TypeScript almost at the same time.

Your Environment

• Version used: 2.0.0-beta.8
• Environment name and version (e.g. Chrome 39, node.js 5.4): Node.js 0.12
• Operating System and version (desktop or mobile): OS X El Capitan 10.11.3

[jbeckton]

Coming from C# I have a habit of using IFoo for interfaces. Regardless of what the guys at Typescript recommend; an interface in Typescript has a different purpose than a class. Typescript interfaces are for compile time anyways, they do not exist in the compiled javascript. So, having a naming convention that allows developers to visually identify an interface from a class makes a lot of sense to me. And I think as far as the compiler goes it could care less if you use an interface vs a class to define a type reference, you could subject yourself to alot of run time errors if you use an interface in place of a class because of a simple mixup. To take the argument a bit further, most anyone can argue that conventions are not needed, the software can still compile and run without them. But the benefits of conventions contribute to quality and productivity. In C# and Java the compiler does not care if you prefix your interfaces with an I, but it's a widely used convention thats been around for years and has more to do with identifying the purpose of the file/code than how it's used in compilation and run time. In Typescript an interface defines a contract, like for a json response from the server or an Api from a third party library and it has no implementation. Sounds alot like interfaces in other platforms so why not prefix it with an I?

[remojansen]

I also come from a Java and C# background and I believe that using I prefix is a good thing. Just like using _ prefix for the private members of a class. I'm aware of the TypeScript recommendation to avoid the I prefix.

I like InversifyJS to be driven by the community not by myself so I have created a survey that you will be able to find here.

I will leave this issue open for some time and see what our users think...

Please participate in the survey.

[mocanu-razvan]

One idea that I came across supporting the view that I prefixes should not be used is that using an I prefix for interfaces avoids the need to properly think about the identifiers used for the interface and implementation classes.

For example, one should not define an ICar interface and an associated Car implements ICar implementation class. Car is the generic identifier here and it should be the one used for the interface. You would want specific, concrete identifiers for your implementation, concrete classes, e.g. SportsCar implements Car, SUVCar implements Car etc. Some other examples: interface PaymentProcessor and concrete class CreditCardPaymentProcessor instead of IPaymentProcessor and PaymentProcessor.

Another view is that prefixing interfaces with I seems to be very similar to hungarian notation in the old days, e.g. szMessage, iCount, pData etc. We should probably be prefixing classes with C if we prefix interfaces with I. In general, I think this solution of using prefixes or suffixes in names to identify their type became obsolete with the advance of static analysis tools that made it trivial to understand what is the type of an identifier.

[tenowg]

I think the I prefixed interface still does have a place, I also come from Java/C# and have used many other languages. My argument is that sometime an interface is just that, an Interface, not a generic identifier. I use abstract classes for alot of things, so I also use an A prefix at times, so it makes it easier in my mind to be able to identify an interface vs. abstract vs. concrete class.

There have been many conventions, but the strongest convention has also always been, be consistent, so if we are going to break convention, always break that convention.

[remojansen]

I've been doing some reading online and everyone in the TypeScript team seems very sure about the idea of not using I prefix. I understand that because most of the people with a Java/C# background (like me) like more the I prefix but I have removed it from the code.

I was thinking about this over the weekend and really is not a big dial because you can still develop your application using the I prefix and the libraries normally don't use this convention (e.g. node.d.ts). The only interfaces that are affected by this are the internal inversify interfaces like IKernel, IContext, IRequest etc. now they are named IKernel, IContext, IRequest.

This will be merged as soon as I get the new inversify.d.ts ready and released as beta.9 once #247 is fixed.

[atrauzzi]

👍 - Totally support not using I prefixes. Even in C#, I think it's another one of those things that people do "just cuz". Like newline braces 😃