下列各節提供設計 CLI 的指引。 想想您的應用程式在命令行上預期的內容，就像 REST API 伺服器在 URL 中預期的情況一樣。 REST API 的一致規則可供用戶端應用程式開發人員使用。 同樣地，如果 CLI 設計遵循常見模式，命令行應用程式的使用者將有較佳的體驗。
建立 CLI 之後，很難加以變更，特別是如果您的使用者已在預期持續執行的腳本中使用您的 CLI。
符號
命令和子命令
如果命令有子命令，則命令應該做為子命令的區域或群組標識碼，而不是指定動作。 當您叫用應用程式時，您可以指定群組命令及其其中一個子命令。 例如，嘗試執行 dotnet tool，而且您會收到錯誤訊息，因為 tool 命令只會識別一組與工具相關的子命令，例如 install 和 list。 您可以執行 dotnet tool install，但 dotnet tool 本身會不完整。
定義區域有助於協助使用者整理說明輸出。
在 CLI 中，通常會有隱含區域。 例如，在 .NET CLI 中，隱含區域是專案，而 Docker CLI 則是映像。 因此，您可以使用 dotnet build 而不包含區域。 請考慮您的 CLI 是否有隱含區域。 如果符合條件，請考慮是否允許使用者選擇性地包含或省略它，如在 docker build 和 docker image build 中。 如果您選擇性地允許使用者輸入默認區域，您將自動為此命令組提供說明指南和自動完成功能。 藉由定義執行相同作業的兩個命令，提供隱含群組的選擇性用法。
選項做為參數
選項應該為命令提供參數，而不是自行指定動作。 這是建議的設計原則，雖然 System.CommandLine 並不總是被遵循（--help 顯示協助資訊）。
命名
簡短格式別名
一般而言，我們建議您將您所定義的簡短格式選項別名數目降到最低。
特別是，請避免使用與 .NET CLI 和其他 .NET 命令行應用程式中的常見用法不同的下列任何別名：
-i為--interactive。此選項會向使用者發出訊號，指出他們可能會收到輸入給命令需要回答的問題。 例如，提示輸入用戶名稱。 您的 CLI 可能會用於文稿，因此在提示尚未指定此參數的使用者時請小心。
-o為--output。某些命令執行後會產生檔案作為結果。 此選項應該用來協助判斷這些檔案應位於何處。 在建立單一檔案的情況下，此選項應該是檔案路徑。 在建立許多檔案的情況下，此選項應該是目錄路徑。
-v為--verbosity。命令通常會在控制臺上向使用者提供輸出;這個選項可用來指定使用者要求的輸出數量。 如需詳細資訊，請參閱
--verbosity本文稍後的選項。
也有一些別名，一般使用方式僅限於 .NET CLI。 您可以將這些別名用於應用程式中的其他選項，但請注意混淆的可能性。
為
-c使用的--configuration這個選項通常是指具名的組建組態，例如
Debug或Release。 您可以使用任何您想要的組態名稱，但大部分工具都預期其中之一。 此設定通常用來以對該組態有意義的方式設定其他屬性，例如，在建Debug置組態時執行較少的程式碼優化。 如果您的命令有不同的作業模式，請考慮此選項。為
-f使用的--framework此選項可用來選取要執行的單一 目標 Framework Moniker （TFM）， 因此，如果您的 CLI 應用程式根據所選 TFM 有不同的行為，您應該支援此旗標。
為
-p使用的--property如果您的應用程式最終會叫用 MSBuild，使用者通常需要以某種方式自定義該呼叫。 此選項可讓 MSBuild 屬性在命令行上提供，並傳遞至基礎 MSBuild 呼叫。 如果您的應用程式不使用 MSBuild，但需要一組鍵-值對，請考慮使用這個相同的選項名稱以符合使用者的期待。
為
-r使用的--runtime如果您的應用程式可以在不同的運行時間上執行，或具有運行時間特定的邏輯，請考慮使用此選項來指定 運行時間識別符。 如果應用程式支援
--runtime，請考慮支援--os和--arch。 這些選項可讓您只指定 OS 或 RID 的架構元件，讓未指定元件從目前的平台判斷。 如需詳細資訊，請參閱 dotnet publish。
簡短名稱
盡可能讓命令、選項和自變數的名稱變得簡短且容易拼字。 例如，如果 class 已足夠清楚，請勿將 命令 classification設為 。
小寫名稱
僅以小寫定義名稱，但您可以建立大寫別名，讓命令或選項不區分大小寫。
Kebab 命名規則
使用 烤肉串大小寫 來區分單字。 例如： --additional-probing-path 。
多元化
在應用程式中，保持複數形式的一致性。 例如，對於可以具有多個值的選項（最大基數大於一），請勿混用複數和單數的名稱：
| 選項名稱 | 一致性 |
|---|---|
--additional-probing-paths 和 --sources |
✔️ |
--additional-probing-path 和 --source |
✔️ |
--additional-probing-paths 和 --source |
❌ |
--additional-probing-path 和 --sources |
❌ |
動詞與名詞
針對那些代表動作的命令，應使用動詞而非名詞來表示。舉例來說：dotnet workload remove，而不是dotnet workload removal。 使用名詞而非動詞選項，例如： --configuration，而非 --configure。
選項 --verbosity
System.CommandLine 應用程式通常會提供 --verbosity 選項，指定傳送至主控台的輸出量。 以下是標準五個設定：
Q[uiet]M[inimal]N[ormal]D[etailed]Diag[nostic]
這些是標準名稱，但現有的應用程式有時會以 Silent 取代 Quiet，並以 Trace、Debug 或 Verbose 取代 Diagnostic。
每個應用程式都會定義自己的準則，以判斷每個層級所顯示的內容。 一般而言，應用程式只需要三個層級：
- 安靜
- 正常
- 診斷
如果應用程式不需要五個不同的層級，此選項仍應定義相同的五個設定。 在此情況下， Minimal 和 Normal 會產生相同的輸出，而且 DetailedDiagnostic 同樣也會相同。 這可讓使用者只輸入他們熟悉的內容，而且會使用最適合的內容。
預期Quiet將不會在控制台上顯示任何輸出。 不過，如果應用程式提供互動式模式，應用程式應該執行下列其中一項動作：
- 當指定
--interactive時，顯示輸入提示，即使--verbosity是Quiet。 - 不允許使用
--verbosity Quiet和--interactive一起使用。
否則，應用程式會等候輸入，而不告知使用者正在等候的內容。 您的應用程式似乎凍結了，而且使用者不知道應用程式正在等候輸入。
如果您定義別名，請使用 -v 來取代 --verbosity，並將沒有參數的 -v 作為 --verbosity Diagnostic 的別名。 請使用 -q 用於 --verbosity Quiet。
.NET CLI 和 POSIX 慣例
.NET CLI 不會一致地遵循所有 POSIX 慣例。
雙虛線
.NET CLI 中的一些命令具有雙破折號符號的特殊實現。 在 dotnet run、dotnet watch 和 dotnet tool run 的情況下，跟隨 -- 的令牌會傳遞至命令所執行的應用程式。 例如：
dotnet run --project ./myapp.csproj -- --message "Hello world!"
^^
在此範例中 --project ，選項會傳遞至 dotnet run 命令，且 --message 其自變數的選項會在執行時當做命令行選項傳遞至 myapp 。
不一定需要令牌即可將選項傳遞至您使用 -- 執行的應用程式。 如果沒有雙破折號，dotnet run 命令會自動將任何無法辨識為適用於dotnet run本身或 MSBuild 的選項，傳遞至正在運行的應用程式。 因此，下列命令行是相等的，因為 dotnet run 無法辨識自變數和選項：
dotnet run -- quotes read --delay 0 --fg-color red
dotnet run quotes read --delay 0 --fg-color red
省略選項與參數之間的分隔符號
.NET CLI 不支援 POSIX 慣例，可讓您在指定單一字元選項別名時省略分隔符。
多個參數不需要重複選項名稱
.NET CLI 不接受一個選項的多個自變數，而不重複選項名稱。
布爾值選項
在 .NET CLI 中，某些布爾值選項在傳遞 false 或 true 時會產生相同的行為。 當實作 選項的 .NET CLI 程式代碼只會檢查選項是否存在或缺少選項時，就會發生此行為，而忽略值。 範例是--no-restore，用於dotnet build命令。 指定 --no-restore false 時，還原作業將會略過，這與您指定 --no-restore true 或 --no-restore 的情況相同。
Kebab 案例
在某些情況下，.NET CLI 不會針對命令、選項或自變數名稱使用kebab案例。 例如，有一個名為--additionalprobingpath而非--additional-probing-path的 .NET CLI 選項。
