這是一個問題，可能沒有一個單一的正確答案，因爲我意識到編碼風格是相當多樣的，特別是在不同的語言之間，例如在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可能僅用於例如在一個返回具體實例的工廠（如果不是工廠，那麼可能仍然只在應用程序的極少數地方與接口的出現次數相比較）。 –