接口的Typescript样式指南

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 names in javascript vs pascal casing methods in C#. I can quite accept that.

Maybe I am over worrying about this, but I am just starting to look into typescript, really like the looks of it and plan to use it along with Angular2, and want to establish a good style guide.

What I really don't get is point 2 here , not to use I prefix for interfaces. Until this, I thought that was almost universal. I have a class Car, so a natural name if the interface is just to add an I in front... ICar. As soon as you see the I prefix you know you have an interface.

I want to follow any suggested practice, but this one I really do not know which why to go.

Does none know why, what I thought was an almost universal convention, is being discouraged here? I know you can use whatever conventions you like, just wondering if there is some reason for this common convention not to be used in Typescript.

Thanks in advance for any opinions/info!

Answer 1

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 Car s 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.

Answer 2

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 3

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 4

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 Users s 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