.NETのインターフェイスの「I」プレフィックス命名規則の背後にある理由は何ですか？

"I"規約がCOM以来存在していたことは知っていますが、.NETが登場する前に他のすべての命名規約のように再検討されなかった理由を理解したことはありません。

消費に関しては、たとえば抽象クラスからインターフェースを分離する唯一のことは、それらが多重継承できることです。しかし、Visual Studio 2003以降のすべてのツールチップには型シグネチャが表示されているため、破棄された他のすべてのハンガリー語の表記と同じくらい役に立ちません。

また、私はそれはあなたが同じ名前を持つインタフェースの基本的な実装を持つことができるようになるかもしれないと思った、例えばMessage継承IMessageが、.NETライブラリのほとんどは（例えば末尾に単語「ベース」を追加するために行っているSystem.Collections.ReadOnlyCollectionBase代わりに） -これはより意味のある意味になります。

COM相互運用機能は別の考えられる理由のようですが、それが生成するラッパークラスが完全に慣用的な.NETであるかのようではないので、それが審美的な考慮事項だったとは思えません。

私の新しいプロジェクトの1つで、私は大会を完全に断念しました。行方不明のものはありますか？

これは、接頭辞が役立つ唯一のケースだと思います。

クラスとインターフェースは実際にはセマンティクスが異なり、どちらも型であるため、簡単に混同できます。
クラス宣言を見ると、それが何から派生していて、何が実装されているかがすぐにわかります。

public sealed class ActivityCollection : List<Activity>, 
    IList<Activity>, ICollection<Activity>, IEnumerable<Activity>, 
    IList, ICollection, IEnumerable

定義が次のように見える場合、理解するのは難しいでしょう。

public sealed class ActivityCollection : ListClass<Activity>, 
    List<Activity>, Collection<Activity>, Enumerable<Activity>, 
    List, Collection, Enumerable

そして、あなたはどのように呼びListClassますか？明らかにListBase、それ自体で使用できるからというだけではありません。
したがって、発明したばかりの問題を解決するか、クラスをインターフェイスから分離するプレフィックスを適用する必要があります。

また、個人的には、メソッドシグネチャから、インターフェイスで機能することを知ることができると便利です。

public void PrintLines (IEnumerable<string> source)

それは私の頭の信号のようなものです：ちょっと、これを実装できます！契約に一致するものなら何でもメソッドにフィードできます。

もちろん、それほど重要ではないと主張することもできますが、これは接頭辞を私にとって価値のあるものにする小さなものの1つです。IoCコンテナを使用して多くのコードを記述し、常にインターフェイスを操作していて、2つを簡単に区別する必要がある場合に特に便利です。

ちなみに、.NET型システムでは、インターフェイスだけに接頭辞が付いているわけではありません。ジェネリック型パラメーターを忘れないでください。

public delegate TResult Func<in T, out TResult>(
    T arg
)

これは、クラスと別の種類の型を区別できることが非常に役立つ別の状況です。

私はあなたが何かを逃したとは思わない、それは単なる歴史的な習慣です。

私もあなたに同意します。また、悪影響を与えることなく、小規模から中規模のいくつかのプロジェクトに「私」をドロップしました。

Microsoftのインターフェイスとクラスに関する命名ガイドラインによると、唯一の理由は、インターフェイスの名前とそれを実装するクラスの間で競合が発生する場合があるためだと思います。これは、インターフェースが実際には骨格ではなく肉であり、実装者クラスが実際に肉（設計図を実現する）であるという事実に戻ります。したがって、IAnimalは動物が何を持っているべきかを説明しているだけですが、Animalは動物が何を持っているかを教えてくれます。

ただし、インターフェースには単にアニマルベースを使用し、クラスにはアニマルを使用できるという点で、私は個人的に完全に同意します。

一方、2つのことが非常に矛盾している場合があるため、チームはすでに決定したにもかかわらず、さらなる矛盾を防ぐための規則を提供することを決定します。たとえば、ASP.NET MVCでは、部分ビューとレイアウト（マスターページ）はどちらも通常のビューと同じですが、機能は異なります。したがって、Microsoftは、名前にアンダースコアを使用しないことを強調しているにもかかわらず、レイアウトとパーシャルビューにアンダースコアを付けることを推奨しています。