Typescript style guide for interfaces

Question

this is a question that may not have a single correct answer, as I do realise coding styles are quite varied, especially between different languages, eg camel case function

Answer 1

Similar question is asked here Confused about the Interface and Class coding guidelines for TypeScript

My answer on it: https://stackoverflow.com/a/41967120/586609

Reasons:

1. The times of the Hungarian notation have passed
2. I-prefix violates encapsulation principle
3. Protection from bad naming
4. Properly chosen names vaccinate you against API Design Myth: Interface as Contract.

Answer 2

There is no reason why to do or not do something other than because it is idiomatic. If you want your code to fit in, you follow the rules everyone else follows in the language you are using and don’t think about it (or pick another language).

As far as specifically why not put a prefix, there are three very good reasons:

1. Interfaces are implicitly created when you use the class keyword, and are also created when you use the type keyword. So, by adding a prefix to your explicitly declared interfaces, now you have some interfaces with a prefix (the ones you created yourself with the prefix), plus a ton more interfaces without a prefix. This is confusing and inconsistent.
2. Types (interfaces) and code exist in independent namespaces in the compiler, so you cannot conflict a type name and a variable name. Therefore there is no reason to try to make interface names unique by prefixing them.
3. I prefixing is just another form of systems hungarian notation; saying a type is an interface provides zero additional information to the human writing the code.

Answer 3

Two more reasons

Modularization As the code base grows, the code starts to be modularized. The usual design goal with modules is to expose contracts and hides the internals. Contracts are best expressed by interfaces and after a while most if not all exposed artifacts are interfaces and factories. For consumers of these modules it is nicer to work with Userss and Credentials rather than IUsers and ICredentials

Alphabetic order For instance quick access to Interfaces and Classes in lists sorted in alphabetic order in a File navigator. When working with Users, it is best to have User, UserService and UserImpl next to each other in the list, rather than having to go though the I entries, then the C entries then the Service entries

Answer 4

I as prefix was big at some time for Java and C# (probably also others) but I don't think this is still considered a good idea but how can one change something that is used by the majority of developers and existing code base.

It's similar to hungarian notation which is universally considered bad practice. Just give it a meaningful name. If you have different kinds of Cars than make Car the universal interface and class FancyCar implements Car is much more natural. Things like prefixes just prevent people from thinking about what they really want to express. See also http://c2.com/cgi/wiki?IntentionRevealingNames

There are also languages like Dart (probably many others I don't know) where there is not such a clear distinction between interface and class. In Dart you can implement any class. The class' interface just acts as an interface.

update

I don't say naming is easy. In fact I think it's the most or at least among the most difficult parts of software development. It's just that the general consesus of "the elite" is that prefixes for technical reasons are not the best approach. This doesn't mean there are alternative that have only advantages and no drawbacks. It seems in this case naming like UserService, UserServiceImpl, MockUserService is used instead. This way in most parts of your code the most natural way UserService is used and the derivates only in prividers. Otherwise, as mentioned above, consistency is way more important. If some style is more common in the language you use, I suggest to use this in your code as well.