接口的Typescript样式指南

Question

这个问题可能没有一个正确的答案，因为我确实认为编码样式是多种多样的，特别是在不同语言之间，例如javascript中的驼峰案例函数和C＃中的pascal大小写方法。我完全可以接受。

也许我对此过于担心，但我只是开始研究打字稿，非常喜欢它的外观，并计划将它与Angular2一起使用，并希望建立一个好的风格指南。

我真正没有得到的是第2点here，不要使用I前缀作为接口。在此之前，我认为这几乎是普遍的。我有一个类Car，所以如果界面只是在前面添加一个自然名称... ICar。只要看到我的前缀，就会知道你有一个界面。

我想遵循任何建议的做法，但这个我真的不知道为什么要去。

没有人知道为什么，我认为这是一个几乎普遍的惯例，在这里被劝阻了？我知道你可以使用你喜欢的任何约定，只是想知道是否有一些理由不能在Typescript中使用这个通用约定。

提前感谢任何意见/信息！

Answer 1

I因为前缀对于Java和C＃（可能还有其他人）来说很重要但是我认为这仍然不是一个好主意但是如何改变大多数人使用的东西开发人员和现有代码库。

它类似于匈牙利符号，这被普遍认为是不好的做法。只要给它一个有意义的名字。如果你有Car种不同于Car，那么通用界面和class FancyCar implements Car就更自然了。像前缀这样的东西只会阻止人们思考他们真正想要表达的内容。另请参阅http://c2.com/cgi/wiki?IntentionRevealingNames

还有像Dart这样的语言（可能是我不知道的其他语言），interface和class之间没有明显的区别。在Dart中，您可以实现任何类。该类的界面仅作为interface。

<强>更新

我不是说命名很容易。事实上，我认为它是软件开发中最难或最难的部分。只是因为“精英”的一般理由是技术原因的前缀并不是最好的方法。这并不意味着有替代方案只有优点而且没有缺点。在这种情况下，似乎使用UserService，UserServiceImpl，MockUserService之类的命名。这种方式在代码的大多数部分中使用最自然的方式UserService，并且仅在私有方中使用派生。否则，如上所述，一致性更为重要。如果某种风格在您使用的语言中更常见，我建议您也在代码中使用它。

Answer 2

此处提出类似问题Confused about the Interface and Class coding guidelines for TypeScript

我的答案：https://stackoverflow.com/a/41967120/586609

理由：

1. 匈牙利符号的时代已经过去了
2. I-prefix违反了封装原则
3. 防止错误命名
4. 正确选择的名称为API Design Myth：Interface as Contract提供接种疫苗。

Answer 3

除了因为它是惯用之外，没有理由做或不做某事。如果您希望您的代码适合，您可以遵循其他人使用的语言遵循的规则，不要考虑它（或选择其他语言）。

具体到为什么不加前缀，有三个很好的理由：

1. 使用typing关键字时会隐式创建接口，并且在使用class关键字时也会创建接口。因此，通过为显式声明的接口添加前缀，现在您有一些带有前缀的接口（您使用前缀自己创建的接口），以及没有前缀的更多接口。这是令人困惑和不一致的。
2. 类型（接口）和代码存在于编译器的独立命名空间中，因此您不能与类型名称和变量名称冲突。因此，没有理由尝试通过为它们添加前缀来使接口名称唯一。
3. type前缀只是匈牙利系统符号的另一种形式;说一个类型是一个接口，为编写代码的人提供零附加信息。

Answer 4

另外两个原因

模块化随着代码库的增长，代码开始模块化。模块的通常设计目标是暴露合同并隐藏内部。合同最好用接口表示，过了一段时间，大多数（如果不是全部）暴露的工件都是接口和工厂。对于这些模块的消费者，使用Users和Credentials而不是IUsers和ICredentials

更好

字母顺序例如，快速访问“文件”导航器中按字母顺序排序的列表中的“接口”和“类”。与用户合作时，最好让列表中的User，UserService和UserImpl彼此相邻，而不必通过I条目，然后C条目然后是Service条目