这是一个问题，可能没有一个单一的正确答案，因为我意识到编码风格是相当多样的，特别是在不同的语言之间，例如在JavaScript中的驼峰案例函数名称与C＃中的pascal套管方法。我完全可以接受这一点。Typescript接口的样式指南
也许我对此感到担心，但我刚开始研究打字稿，真的很喜欢它的外观，并打算将它与Angular2一起使用，并希望建立一个良好的风格指南。
我真的没有得到的是第2点here，不要使用I前缀作为接口。在此之前，我认为这几乎是普遍的。我有一个班车，所以一个自然的名字，如果界面只是在前面添加一个我... ICar。只要你看到我的前缀，你就知道你有一个接口。
我想遵循任何建议的做法，但这一个我真的不知道为什么要去。
没有人知道为什么，我认为是一个几乎普遍的约定，在这里感到沮丧吗？我知道你可以使用任何你喜欢的约定，只是想知道这个常见约定是否有一些原因不能用在Typescript中。
在此先感谢您的任何意见/信息！
I作为Java和C＃（也可能是其他人）的前缀很大，但我不认为这仍然被认为是一个好主意，但如何改变大多数开发人员使用的和现有的东西代码库。
它与被普遍认为是不好的做法的匈牙利符号相似。只要给它一个有意义的名字。如果你有不同种类的Car s比Car通用接口和class FancyCar implements Car更自然。像前缀这样的事情只会阻止人们思考他们真正想表达的内容。另请参阅http://c2.com/cgi/wiki?IntentionRevealingNames
也有像Dart这样的语言（可能是许多其他我不知道的），在interface和class之间没有这样明显的区别。在Dart中，您可以实施任何课程。该类的接口只是作为interface。
更新
我就不多说了命名很容易。事实上，我认为这是软件开发中最困难或最困难的部分。只是，“精英”的普遍观点是，出于技术原因的前缀不是最好的方法。这并不意味着有其他的选择，只有优点，没有缺点。在这种情况下，似乎命名为UserService,UserServiceImpl,MockUserService。通过这种方式，在代码的大多数部分中，最自然的方式是使用UserService，并且派生函数仅在prividrs中派生。否则，如上所述，一致性更重要。如果某种风格在您使用的语言中更常见，我建议您也可以在代码中使用它。
没有理由为什么要做或不做别的，因为它是惯用的。如果你希望你的代码适合你，你遵循其他人遵循的规则，并且不要考虑它（或者选择另一种语言）。
至于具体为什么不把前缀，有三个很好的理由：当您使用class关键字，当你使用type关键字还创建
I前缀只是匈牙利符号系统的另一种形式;说一个类型是一个接口向编写代码的人提供附加信息零。@C Snover它不告诉编码器他们正在处理多态行为？ – gravidThoughts
值得注意的是，截至2017年3月，Microsoft仍建议在C＃中使用“I”前缀：https：//docs.microsoft.com/en-us/dotnet/standard/design-guidelines/names-of-classes-structs-和接口 –
TypeScript和C＃不是相同的语言，因此它们没有相同的约定。这是令人困惑的，我知道。 ;）[Microsoft对TypeScript本身的编码准则]（https://github.com/Microsoft/TypeScript/wiki/Coding-guidelines#names）禁止使用I前缀。 –
类似的问题在这里问Confused about the Interface and Class coding guidelines for TypeScript
我就可以了回答：https://stackoverflow.com/a/41967120/586609
原因：
两个以上的原因
模块化随着代码库的增长，代码开始模块化。模块通常的设计目标是公开契约并隐藏内部。合同最好由接口表示，过了一段时间后，大部分（如果不是全部）暴露的工件都是接口和工厂。对于消费者来说，这些模块是更好的在文件导航字母顺序排序的列表与Users S和Credentials而不是IUsers和ICredentials
字母顺序例如快速访问接口和类的工作。当与用户的工作，最好是有User，UserService和UserImpl彼此相邻列表，而不是去虽然I条目，那么C条目则Service项
谢谢你。我现在已经习惯了它，现在也意识到TypeScript中的接口也比C＃这样的语言更通用一些。 – peterc
感谢您的反馈意见。当你为了多形态的原因使用接口时，FancyCar实现了Car等参数。说一个Angular服务，将会有一个例子，例如'FileSystemService'，'UserService'，我们可以将它们全部实现到一个接口，所以我们总是将接口而不是具体类注入服务使用者。这样就可以轻松地模拟类到接口等。这意味着您需要为每个服务的接口考虑一个替代名称，而不是简单的前缀（例如'IFileSystemService'，'IUserService'）。 – peterc
再次感谢您的意见。我想我们可以使用后缀而不是前缀，但直到同样的事情到底是不是？我想我们也会使用'FileSystemServiceInterface'。我在接口中看到了很多带有“I”的教程（由js中的高度尊重的权威人士），这就是为什么我最初认为它会遵循类似的惯例来使用基于lclass的语言，例如C＃（它全部使用它时间），以及为什么当我后来看到风格指南时感到惊讶，并且它特别针对这一个惯例。所有的思想食物。 – peterc
我认为我的意图是，如我以前的评论所述，不要在**接口**上使用前缀或后缀，因为这通常是整个应用程序中使用的前缀或后缀，而UserServiceImpl可能仅用于例如在一个返回具体实例的工厂（如果不是工厂，那么可能仍然只在应用程序的极少数地方与接口的出现次数相比较）。 –