10分以内で学ぶ C# 10 と .NET 6 の Global Usings

繰り返しの問題

[0:17 - 1:50] Timは新しい.NET 6コンソールアプリを使い始め、DataフォルダにPersonModelクラスを作成します。 Program.csからそのクラスを参照するには、ファイルの先頭に期待されるPersonModelを必要とする2番目のクラスを追加することは、そのファイルの先頭に同じusing行を追加することを意味します。 半ダースのクラスで、同じインポートが半ダース回も記述されます。

これはまさにglobal usingのために設計された状況です。 プロジェクト全体が依存する任何の名前空間、型、または静的クラスは、一度宣言されれば、ファイルごとの再ステートメントなしにすべてのファイルに利用可能になります。

Usingをグローバルスコープに昇格

[1:50 - 2:24] 構文は既存のディレクティブの前に単一のキーワードです。

global using GlobalUsings.Data;

global using GlobalUsings.Data;

プロジェクトの任意の.csファイルに配置されたその1行が、同じプロジェクト内の他のすべてのファイルにGlobalUsings.Dataを利用可能にします。 以前はPersonModelのための独自のusing行を必要としていた他のクラスは、もはやそれを必要としません。 タイプは自動的に解決されます。 スコープはプロジェクトの境界で止まりますので、姉妹プロジェクトからクラスを参照するには通常のプロジェクト参照に加えて、独自のグローバルまたはファイルごとのusingが必要です。

これがしないことは、タイプの由来の隠蔽です。 コンパイラはPersonModelをその名前空間に解決し続けます。 名前空間は単に事前にインポートされています。 実行時の動作は、すべてのファイルの上部に同じusingを書くのと同じです。

Usingの中央化を1つのファイルへ

[2:24 - 3:32] ランダムなファイルにグローバルusingディレクティブを振りかけることは技術的には有効ですが、操作上は乱雑になります。 新しいチームメンバーがPersonModelが明示的なインポートなしで解決されるのを見ると、プロジェクトのどこでグローバルにされたのかを見つけるためにgrepしなければなりません。 進化する慣習は、すべてのグローバルusingをプロジェクトルートの単一ファイルに保持し、Usings.csやGlobalUsings.csのように予測可能な名前を付けることです:

// Usings.cs at the project root
global using GlobalUsings.Data;
global using System.Text.Json;
global using System.Collections.Concurrent;

// Usings.cs at the project root
global using GlobalUsings.Data;
global using System.Text.Json;
global using System.Collections.Concurrent;

ファイルには他には何も含まれません。 プロジェクトに加わる人は、グローバルに利用可能なものを確認するために正確に1つの場所を知っています。 これはファイルスコープの名前空間や他の儀式削減機能と共鳴し、最近のC#リリースに導入され、プロジェクトのボイラープレートを視覚的に読みやすくします。

メソッドインポートのためのGlobal Using Static

[3:32 - 4:50] グローバルusingディレクティブは、以前に追加されたusing static形式と組み合わせて作成します。 この組み合わせを使用すると、クラス プレフィックスをプロジェクト全体の静的クラス メンバーから削除できます。 Timが示すモチベーションのケースはConsole.WriteLineです。

global using static System.Console;

global using static System.Console;

集中化されたusingsファイルにその1行を加えることで、プロジェクト全体でWriteLine("hello")になります。 同じパターンは、数学ヘルパー（global using static System.Mathを使用すると、接頭辞なしでSqrt(x)と書ける）や、コードベースで頻繁に使用する他の静的クラスにも機能します。

これは、ティムが最も慎重を期す形式です。 メソッドが明白な場合、クラスプレフィックスを削除することは読みやすさの向上ですが、2つの静的クラスが同じ名前のメソッドを公開する場合には混乱の原因となる可能性があります。 素のWriteLine呼び出しを見る読者は、文脈でソースを見ずに中央のファイルを信頼しなければなりません。

グローバルインポートが互いに妨害するとき

[4:50 - 5:14] 名前空間の目的は、同じ短い名前を持つタイプが衝突しないようにすることです。 名前空間をグローバルにインポートすることで、プロジェクト全体のバッファを一度に削除します。 あなたのSystem.Dataをグローバルにインポートすると、現在、すべてのファイルで曖昧さを解消する必要があります。 コストは衝突が発生した場所ではなく、2つの間に挟まれる将来のファイルで発生します。

ティムのガイドラインは、グローバルusingを意図的に使用し、プロジェクトが普遍的に依存している名前空間を優先し、グローバルusing静的に特別に注意を払い続けることです。 合理的な初期セットは、すべてのファイルがとにかくインポートする名前空間であり、 それを超えてリストを拡大するにはコードレビューが必要です。

まとめ: より少ない儀式、同じ振る舞い

[5:14 - 5:33] グローバルusingはプロジェクトのライフタイムを通じて利益をもたらす小さな特徴です。 もはや5行の冗長なインポートを持たないすべてのファイルは、実際のコードがより速く開くファイルであり、共有名前空間への編集は数十箇所ではなく1箇所で発生します。 型エイリアスや広範なusingファミリーに入れる同じ注意をここにも適用します: 読みやすさの向上が明確である場所で使用し、次の開発者が一目でスキャンできるよう中央ファイルを小さく保ってください。

結論

[5:14 - 5:33] グローバルusingはファイルごとのusing行をプロジェクト全体のディレクティブに置き換え、グローバルusing静的バリアントは静的メンバー呼び出しからクラスプレフィックスを削除し、プロジェクトルートの単一Usings.csファイルが可視性を保ちます。 特徴はオプトインおよび追加なので、既存のコードベースに採用するのは段階的です。

例ティップ: System.Collections.Genericのようなキュレーションされた一連のグローバルusingを、作成しなくても自動的に追加します。 それを自身のUsings.csと組み合わせてプロジェクト固有のインポートを行えば、すべてのファイルの冒頭が明らかに短縮されます。

彼のYouTubeチャンネルでビデオを完全に視聴して、10-Minute TrainingシリーズでのモダンなC#プロジェクト構造に関するさらなる洞察を得てください。