You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: documentation/development-docs/azure-powershell-design-guidelines.md
+19-26Lines changed: 19 additions & 26 deletions
Original file line number
Diff line number
Diff line change
@@ -7,8 +7,7 @@
7
7
- [Verb-Noun Format](#verb-noun-format)
8
8
- [Pascal Case](#pascal-case)
9
9
- [Noun Prefix](#noun-prefix)
10
-
- [Specific Noun](#specific-noun)
11
-
- [Noun Singularity](#noun-singularity)
10
+
- [Specific Noun and Noun Singularity](#specific-noun-and-noun-singularity)
12
11
- [Set vs. Update](#set-vs-update)
13
12
- [Cmdlet Alias](#cmdlet-alias)
14
13
-[Output Type](#output-type)
@@ -54,31 +53,25 @@ The following are naming conventions to keep in mind when coming up with a name
54
53
55
54
#### Verb-Noun Format
56
55
57
-
Cmdlet names should follow the _Verb-Noun_ format, where the verb is from the [list of approved PowerShell verbs](https://msdn.microsoft.com/en-us/library/ms714428(v=vs.85).aspx), and the noun is a specific noun describing a resource within your service.
56
+
Cmdlet names should follow the _Verb-Noun_ format, where the verb is from the [list of approved PowerShell verbs](https://docs.microsoft.com/en-us/powershell/developer/cmdlet/approved-verbs-for-windows-powershell-commands), and the noun is a specific noun describing a resource within your service.
58
57
59
58
#### Pascal Case
60
59
61
-
From the [Strongly Encouraged Development Guidelines](https://msdn.microsoft.com/en-us/library/dd878270(v=vs.85).aspx):
60
+
From the [Strongly Encouraged Development Guidelines](https://docs.microsoft.com/en-us/powershell/developer/cmdlet/strongly-encouraged-development-guidelines#use-pascal-case-for-cmdlet-names-sd02):
62
61
63
62
> _Use Pascal case for cmdlet names. In other words, capitalize the first letter of the verb and all terms used in the noun. For example, "Clear-ItemProperty"._
64
63
65
64
#### Noun Prefix
66
65
67
66
For ARM cmdlets, the noun must be prefixed with `Az`. For RDFE and data plane cmdlets, the noun must be prefixed with `Azure`.
68
67
69
-
#### Specific Noun
68
+
#### Specific Noun and Noun Singularity
70
69
71
-
From the [Strongly Encouraged Development Guidelines](https://msdn.microsoft.com/en-us/library/dd878270(v=vs.85).aspx):
70
+
From the [Strongly Encouraged Development Guidelines](https://docs.microsoft.com/en-us/powershell/developer/cmdlet/strongly-encouraged-development-guidelines#use-a-specific-noun-for-a-cmdlet-name-sd01):
72
71
73
72
> _Nouns used in cmdlet naming need to be very specific so that the user can discover your cmdlets. Prefix generic nouns such as "server" with a shortened version of the product name. For example, if a noun refers to a server that is running an instance of Microsoft SQL Server, use a noun such as "SQLServer". The combination of specific nouns and the short list of approved verbs enable the user to quickly discover and anticipate functionality while avoiding duplication among cmdlet names._
74
-
75
-
#### Noun Singularity
76
-
77
-
Similar to parameters (mentioned below), avoid using plural nouns when naming cmdlets. From the [Strongly Encouraged Development Guidelines](https://msdn.microsoft.com/en-us/library/dd878270(v=vs.85).aspx):
78
-
79
-
> _Avoid using plural names for parameters whose value is a single element. This includes parameters that take arrays or lists because the user might supply an array or list with only one element._
80
73
>
81
-
>_Plural parameter names should be used only in those cases where the value of the parameter is always a multiple-element value. In these cases, the cmdlet should verify that multiple elements are supplied, and the cmdlet should display a warning to the user if multiple elements are not supplied._
74
+
>_To enhance the user experience, the noun that you choose for a cmdlet name should be singular. For example, use the name `Get-Process` instead of `Get-Processes`. It is best to follow this rule for all cmdlet names, even when a cmdlet is likely to act upon more than one item._
82
75
83
76
#### Set vs. Update
84
77
@@ -122,23 +115,23 @@ The `Force` parameter is reserved for special scenarios where additional confirm
122
115
123
116
The following are naming conventions to keep in mind when coming up with a name for your parameters.
124
117
125
-
In addition, a recommended list of parameter names can be found [here](https://msdn.microsoft.com/en-us/library/ms714468(v=vs.85).aspx).
118
+
In addition, a recommended list of parameter names can be found [here](https://docs.microsoft.com/en-us/powershell/developer/cmdlet/standard-cmdlet-parameter-names-and-types).
126
119
127
120
#### Standard Parameter Name
128
121
129
-
From the [Strongly Encouraged Development Guidelines](https://msdn.microsoft.com/en-us/library/dd878270(v=vs.85).aspx):
122
+
From the [Strongly Encouraged Development Guidelines](https://docs.microsoft.com/en-us/powershell/developer/cmdlet/strongly-encouraged-development-guidelines#use-standard-parameter-names):
130
123
131
124
> _Your cmdlet should use standard parameter names so that the user can quickly determine what a particular parameter means. If a more specific name is required, use a standard parameter name, and then specify a more specific name as an alias. For example, the `Get-Service` cmdlet has a parameter that has a generic name (**Name**) and a more specific alias (**ServiceName**). Both terms can be used to specify the parameter._
132
125
133
126
#### Pascal Case
134
127
135
-
Similar to cmdlets (mentioned above), parameters should follow pascal casing.From the [Strongly Encouraged Development Guidelines](https://msdn.microsoft.com/en-us/library/dd878270(v=vs.85).aspx):
128
+
Similar to cmdlets (mentioned above), parameters should follow pascal casing.From the [Strongly Encouraged Development Guidelines](https://docs.microsoft.com/en-us/powershell/developer/cmdlet/strongly-encouraged-development-guidelines#use-pascal-case-for-parameter-names):
136
129
137
-
> _Use Pascal case for cmdlet names. In other words, capitalize the first letter of the verb and all terms used in the noun. For example, "Clear-ItemProperty"._
130
+
> _Use Pascal case for parameter names. In other words, capitalize the first letter of each word in the parameter name, including the first letter of the name._
138
131
139
132
#### Singularity
140
133
141
-
From the [Strongly Encouraged Development Guidelines](https://msdn.microsoft.com/en-us/library/dd878270(v=vs.85).aspx):
134
+
From the [Strongly Encouraged Development Guidelines](https://docs.microsoft.com/en-us/powershell/developer/cmdlet/strongly-encouraged-development-guidelines#use-singular-parameter-names):
142
135
143
136
> _Avoid using plural names for parameters whose value is a single element. This includes parameters that take arrays or lists because the user might supply an array or list with only one element._
144
137
>
@@ -150,13 +143,13 @@ If you there is a separate nomenclature for the parameter name, or if you would
150
143
151
144
### Bool vs. SwitchParameter
152
145
153
-
Parameters of type `bool` are _strongly_ discouraged in PowerShell. The `SwitchParameter` type of a parameter acts a flag that signals whether or not some action should be taken based on if the parameter was provided or not. From the [Strongly Encouraged Development Guidelines](https://msdn.microsoft.com/en-us/library/dd878270(v=vs.85).aspx):
146
+
Parameters of type `bool` are _strongly_ discouraged in PowerShell. The `SwitchParameter` type of a parameter acts a flag that signals whether or not some action should be taken based on if the parameter was provided or not. From the [Strongly Encouraged Development Guidelines](https://docs.microsoft.com/en-us/powershell/developer/cmdlet/strongly-encouraged-development-guidelines#parameters-that-take-true-and-false):
154
147
155
148
> _If your parameter takes only true and false, define the parameter as type SwitchParameter. A switch parameter is treated as true when it is specified in a command. If the parameter is not included in a command, Windows PowerShell considers the value of the parameter to be false. Do not define Boolean parameters._
156
149
157
150
### Closed Set of Values
158
151
159
-
If there is a closed set of values applicable for a given parameter, use either a `ValidateSet`, enumeration type, or an `ArgumentCompleter`. This functionality allows users to tab through the different values they can provide. From the [Strongly Encouraged Development Guidelines](https://msdn.microsoft.com/en-us/library/dd878270(v=vs.85).aspx):
152
+
If there is a closed set of values applicable for a given parameter, use either a `ValidateSet`, enumeration type, or an `ArgumentCompleter`. This functionality allows users to tab through the different values they can provide. From the [Strongly Encouraged Development Guidelines](https://docs.microsoft.com/en-us/powershell/developer/cmdlet/strongly-encouraged-development-guidelines#parameters-that-take-a-list-of-options):
160
153
161
154
> _There are two ways to create a parameter whose value can be selected from a set of options._
162
155
>
@@ -167,7 +160,7 @@ In addition, you can choose to add an `ArgumentCompleter` to a parameter to allo
167
160
168
161
### Consistent Parameter Types
169
162
170
-
From the [Strongly Encouraged Development Guidelines](https://msdn.microsoft.com/en-us/library/dd878270(v=vs.85).aspx):
163
+
From the [Strongly Encouraged Development Guidelines](https://docs.microsoft.com/en-us/powershell/developer/cmdlet/strongly-encouraged-development-guidelines#use-consistent-parameter-types):
171
164
172
165
> _When the same parameter is used by multiple cmdlets, always use the same parameter type. For example, if the **Process** parameter is an **Int16** type for one cmdlet, do not make the **Process** parameter for another cmdlet a **UInt16** type._
173
166
@@ -179,7 +172,7 @@ The following are naming conventions to keep in mind when coming up with a name
179
172
180
173
#### Pascal Case
181
174
182
-
Similar to cmdlets (mentioned above), parameter set names should follow pascal casing. From the [Strongly Encouraged Development Guidelines](https://msdn.microsoft.com/en-us/library/dd878270(v=vs.85).aspx):
175
+
Similar to cmdlets (mentioned above), parameter set names should follow pascal casing. From the [Strongly Encouraged Development Guidelines](https://docs.microsoft.com/en-us/powershell/developer/cmdlet/strongly-encouraged-development-guidelines#use-pascal-case-for-cmdlet-names-sd02):
183
176
184
177
> _Use Pascal case for cmdlet names. In other words, capitalize the first letter of the verb and all terms used in the noun. For example, "Clear-ItemProperty"._
185
178
@@ -189,23 +182,23 @@ The following are guidelines that should be followed when working with the attri
189
182
190
183
#### Mutually Exclusive Parameter Sets
191
184
192
-
For PowerShell to determine which parameter set a user is intending to use with a set of provided parameters, the parameter sets need to be designed in such a way that they are mutually exclusive. From the remarks section of [Parameter Attribute Declaration](https://msdn.microsoft.com/en-us/library/ms714348(v=vs.85).aspx):
185
+
For PowerShell to determine which parameter set a user is intending to use with a set of provided parameters, the parameter sets need to be designed in such a way that they are mutually exclusive. From the remarks section of [Parameter Attribute Declaration](https://docs.microsoft.com/en-us/powershell/developer/cmdlet/parameter-attribute-declaration#remarks):
193
186
194
187
> _Each parameter set must have at least one unique parameter. Good cmdlet design indicates this unique parameter should also be mandatory if possible. If your cmdlet is designed to be run without parameters, the unique parameter cannot be mandatory._
195
188
196
189
#### Positional Parameters Limit
197
190
198
-
It is possibile to call a PowerShell cmdlet without providing the parameter names, but just the values you would like to pass through. This is done by specifying the position at which the value of each parameter should be provided by using the `Position` property for a parameter. However, when there are too many positional parameters in a single parameter set, it can be difficult for the user to remember the exact ordering in which the parameter values should be provided. From the remarks section of [Parameter Attribute Declaration](https://msdn.microsoft.com/en-us/library/ms714348(v=vs.85).aspx):
191
+
It is possibile to call a PowerShell cmdlet without providing the parameter names, but just the values you would like to pass through. This is done by specifying the position at which the value of each parameter should be provided by using the `Position` property for a parameter. However, when there are too many positional parameters in a single parameter set, it can be difficult for the user to remember the exact ordering in which the parameter values should be provided. From the remarks section of [Parameter Attribute Declaration](https://docs.microsoft.com/en-us/powershell/developer/cmdlet/parameter-attribute-declaration#remarks):
199
192
200
193
> _When you specify positional parameters, limit the number of positional parameters in a parameter set to less than five. And, positional parameters do not have to be contiguous. Positions 5, 100, and 250 work the same as positions 0, 1, and 2._
201
194
202
-
In addition, there should be no two parameters with the same position in the same parameter set. From the remarks section of [Parameter Attribute Declaration](https://msdn.microsoft.com/en-us/library/ms714348(v=vs.85).aspx):
195
+
In addition, there should be no two parameters with the same position in the same parameter set. From the remarks section of [Parameter Attribute Declaration](https://docs.microsoft.com/en-us/powershell/developer/cmdlet/parameter-attribute-declaration#remarks):
203
196
204
197
> _No parameter set should contain more than one positional parameter with the same position._
205
198
206
199
#### ValueFromPipeline Limit
207
200
208
-
Allowing the user to pipe an object from one cmdlet to another is a major scenario in PowerShell, but allowing multiple parameters in the same parameter set to accept their value from the pipeline can cause issues. From the remarks section of [Parameter Attribute Declaration](https://msdn.microsoft.com/en-us/library/ms714348(v=vs.85).aspx):
201
+
Allowing the user to pipe an object from one cmdlet to another is a major scenario in PowerShell, but allowing multiple parameters in the same parameter set to accept their value from the pipeline can cause issues. From the remarks section of [Parameter Attribute Declaration](https://docs.microsoft.com/en-us/powershell/developer/cmdlet/parameter-attribute-declaration#remarks):
209
202
210
203
> _Only one parameter in a parameter set should declare ValueFromPipeline = true. Multiple parameters can define ValueFromPipelineByPropertyName = true._
0 commit comments