より広範な質問：
そのような標準が課されていることを聞いたことがありますか？もしそうなら、その背後にある理由は何でしたか？
はい、私はこれを聞いたことがあり、完全修飾オブジェクト名を使用すると、名前の衝突を防ぎます。まれではありますが、発生した場合、それらを把握するのは非常に厄介です。
例：
このタイプのシナリオは、おそらく例を使用してより適切に説明されます。
我々は2持っていると言うLists<T>二つの別々のプロジェクトに属します。
System.Collections.Generic.List<T>
MyCorp.CustomCollections.Optimized.List<T>
完全修飾オブジェクト名を使用すると、どちらList<T>が使用されているかが明確になります。その明瞭さは明らかに冗長性を犠牲にしてもたらされます。
そして、あなたは「待って！誰もそのようなリストを2つ使用することはないだろう！」と主張するかもしれません。ここでメンテナンスシナリオを指摘します。
Foo承認され最適化された企業を使用する企業向けのモジュールを作成しましたList<T>。
using MyCorp.CustomCollections.Optimized;
public class Foo {
List<object> myList = ...;
}
後で、新しい開発者があなたがやってきた仕事を延長することにしました。会社の基準を知らずに、usingブロックを更新します。
using MyCorp.CustomCollections.Optimized;
using System.Collections.Generic;
そして、急いで物事がどのように悪くなるかを見ることができます。
同じプロジェクト内の異なる名前空間にある同じ名前の2つの独自クラスを持つことができることを指摘するのは簡単なはずです。そのため、.NETフレームワークが提供するクラスとの衝突に関する懸念だけではありません。
MyCorp.WeightsAndLengths.Measurement();
MyCorp.TimeAndSpace.Measurement();
現実：
さて、これはほとんどのプロジェクトで起こりそうですか？いいえ、そうでもありません。しかし、多くの入力がある大規模なプロジェクトで作業しているときは、物事が爆発する可能性を最小限に抑えるために最善を尽くします。
複数の貢献チームを持つ大規模プロジェクトは、アプリケーションの世界では特別な種類の獣です。プロジェクトへの入力ストリームと、貢献者がプロジェクトのガイドラインを読んでいない可能性があるため、他のプロジェクトにとって不合理と思われるルールがより適切になります。
これは、2つの大きなプロジェクトが一緒にマージされるときにも発生する可能性があります。両方のプロジェクトに同じ名前のクラスがある場合、1つのプロジェクトから別のプロジェクトへの参照を開始すると衝突が発生します。また、プロジェクトが大きすぎてリファクタリングできない場合や、経営陣がリファクタリングに費やした時間を賄うための費用を承認しない場合もあります。
代替案：
質問はしませんでしたが、これは問題の優れた解決策ではないことを指摘する価値があります。名前空間宣言なしで衝突するクラスを作成するのは得策ではありません。
List<T>、特に、予約語として扱われ、クラスの名前として使用されるべきではありません。
同様に、プロジェクト内の個々の名前空間は、一意のクラス名を持つよう努める必要があります。どのネームスペースを使用しているのFoo()かを思い出して思い出す必要があるのは、精神的なオーバーヘッドです。持つ：別の方法が言ったMyCorp.Bar.Foo()とMyCorp.Baz.Foo()、あなたの開発者まで、最高の回避をトリップする予定です。
それ以外の場合は、あいまいさを解決するために部分的な名前空間を使用できます。たとえば、どちらのFoo()クラスも絶対に名前を変更できない場合は、部分的な名前空間を使用できます。
Bar.Foo()
Baz.Foo()
現在のプロジェクトの具体的な理由：
その基準に従って現在のプロジェクトに与えられた特定の理由で質問を更新しました。それらを見て、バニートレイルを本当に脱線しましょう。
完全に修飾された型を取得するには、名前の上にマウスを移動するのは面倒です。常に完全修飾型を常に表示することをお勧めします。
「面倒？」いいえ。おそらく迷惑です。画面上のポインターを移動するために数オンスのプラスチックを移動するのは面倒ではありません。しかし、私は脱線します。
この推論の行は、他の何よりも隠蔽のように見えます。ちなみに、アプリケーション内のクラスの名前は弱く、クラス名を取り巻く適切な量のセマンティック情報を収集するには、名前空間に依存する必要があると思います。
これは完全修飾クラス名の有効な正当化ではありません。おそらく、部分修飾クラス名を使用する正当な正当化です。
電子メールで送信されたコードスニペットには完全修飾名がないため、理解が難しい場合があります。
この（続き？）の推論の行は、クラスの名前が現在不十分であるという私の疑念を補強します。繰り返しますが、貧弱なクラス名を持っていることは、すべてが完全修飾クラス名を使用することを要求するための良い正当化ではありません。クラス名を理解するのが難しい場合、完全修飾クラス名で修正できるものよりも多くの間違いがあります。
Visual Studioの外部（Notepad ++など）でコードを表示または編集する場合、完全修飾型名を取得することはできません。
すべての理由のうち、これは私に飲み物を吐き出させた。しかし、再び、私は脱線します。
チームがVisual Studioの外部でコードを頻繁に編集または表示しているのはなぜだろうかと思います。そして今、私たちは、名前空間が提供するものとかなり直交する正当性を検討しています。これはツールに裏打ちされた引数ですが、名前空間はコードに組織構造を提供するためにあります。
あなた自身のプロジェクトは、ツールが彼らに提供できるものを利用していない開発者とともに、貧弱な命名規則に苦しんでいるように思えます。そして、それらの実際の問題を解決するのではなく、症状の1つを介してバンドエイドを平手打ちしようとし、完全修飾クラス名を要求しています。これを誤ったアプローチとして分類しても安全だと思います。
適切に名前が付けられていないクラスがあり、リファクタリングできないと仮定した場合、正しい答えはVisual Studio IDEを最大限に活用することです。VS PowerToolsパッケージのようなプラグインの追加を検討してください。次に、AtrociouslyNamedClass()クラス名をクリックしてF12を押し、クラスの定義に直接移動して、何をしようとしているのかをよりよく理解することができます。同様に、Shift-F12をクリックして、現在使用する必要があるコード内のすべてのスポットを見つけることができますAtrociouslyNamedClass()。
外部のツーリングの懸念に関して-行うための最善のことは、それを止めることです。参照先がすぐにわからない場合は、スニペットをメールでやり取りしないでください。Visual Studio以外のツールには、チームが必要とするコードを取り巻くインテリジェンスがないため、使用しないでください。Notepad ++は素晴らしいツールですが、このタスクには適していません。
ですから、あなたが提示された3つの特定の正当化に関するあなたの評価に同意します。そうは言っても、「このプロジェクトには対処できない/対処できない根本的な問題があり、これが私たちがそれらを「修正」する方法です」と言われたと思います。そして、それは明らかに、チーム内のより深刻な問題を物語っています。