Update Writing-Parameter-Blocks.md

- Change "what it's expected or allowed values are" to "what its expected or allowed values are" as clearly "it's" cannot mean 'it is' or 'it has' in this context and is thus incorrect.
- Change 'You should support --whatif' to 'You should support -WhatIf' as that's the correct casing. Also, the double dash has been changed to a single dash because this is PowerShell, not sh, bash, zsh or something like that.
- Remove the unnecessary semicolon at the end of the line in the example code.
- Change some small typos and remove more than one blank line in several places.

P.S. Consider using single quotes for strings with constant values instead of double quotes! Using PSScriptAnalyzer will catch these! By the way, consider recommending using PSScriptAnalyzer, because using that will generally improve one's code significantly!

Author: richy58729

Best-Practices/Writing-Parameter-Blocks.md

@@ -36,7 +36,7 @@ function Test-Help {
 ```
 ### Always Document Every Parameter
 
-You should always provide at least a brief explanation of each parameter, what it's expected or allowed values are, etc.
+You should always provide at least a brief explanation of each parameter, what its expected or allowed values are, etc.
 
 The best place for this is a simple comment directly above the parameter (inside the param block) so you don't forget to update it if you remove, rename, or otherwise change the parameter, but you can also place them in the comment help block by using `.PARAMETER ParameterName` and writing the help on the next line.
 
@@ -50,9 +50,9 @@ There are a few specific advanced cases where you might want to write an old-fas
 
 If you have more than one ParameterSetName on your parameters, you should specify one of them as the `DefaultParameterSetName` in the CmdletBinding.
 
-## You should support --whatif
+## You should support -WhatIf
 
-If you write a command that changes state, you should probably add `SupportsShouldProcess` to your CmdletBinding. This allows users to specify `-WhatIf` and `-Confirm` when calling your command, so you'll need to actually support those by using `$PSCmdlet.ShouldProcess(...)` or `$PSCmdlet.ShouldContinue(...)` or by passing the preference variable on to other commands you're calling (e.g. `-Whatif:$WhatIfPreference`).
+If you write a command that changes state, you should probably add `SupportsShouldProcess` to your CmdletBinding. This allows users to specify `-WhatIf` and `-Confirm` when calling your command, so you'll need to actually support those by using `$PSCmdlet.ShouldProcess(...)` or `$PSCmdlet.ShouldContinue(...)` or by passing the preference variable on to other commands you're calling (e.g., `-Whatif:$WhatIfPreference`).
 
 Here's an example of what that might look like:
 
@@ -63,13 +63,13 @@ Here's an example of what that might look like:
 param([switch]$Force)
 
 # You need to pre-define these (because they're passed by [ref])
-$RejectAll = $false;
-$ConfirmAll = $false;
+$RejectAll = $false
+$ConfirmAll = $false
 
 # Note: please don't actually do this with services, restarting them in non-dependency order would be a nightmare...
 foreach ($service in Get-Service | Where Status -eq "Running") {
     # This will normally automatically be TRUE. It will only query if the user:
-    # 1. Has their $ConfirmPreference (default High) set LOWER or equal to the ConfirmImpact in the cmdlet binding (default Medium)
+    # 1. Has their $ConfirmPreference (default High) set LOWER than or equal to the ConfirmImpact in the cmdlet binding (default Medium)
     # 2. Passes -Confirm, which sets the $ConfirmPreference in the function's scope to Low
     if ($PSCmdlet.ShouldProcess( "Restarted the service '$($service.Name)'",
                                  "Restart the '$($service.DisplayName)' service ($($service.Name))?",
@@ -93,13 +93,11 @@ foreach ($service in Get-Service | Where Status -eq "Running") {
 
 Although PowerShell is a dynamic language, we can specify types, and in parameters, it's particularly useful.
 
-
 First, because it hints to users what sort of values they can pass to your command. Is it numeric? Text? An object?
 
 Second, because using types on parameters helps validate the input, which is crucial because parameters are where you get your user input. Strong types can help you avoid code injection and other problems with user inputs, and will allow failures to happen as early as possible (even before your command is called).
 
-Additionally, when passing on parameters to another command, you should be _at least_ as strongly typed as the other command, to avoid casting exceptions within your script.
-
+Additionally, when passing on parameters to another command, they should be _at least_ as strongly typed as the other command, to avoid casting exceptions within your script.
 
 ### Be careful with `[string]` or `[object]` (and `[PSObject]`)
 
@@ -122,9 +120,8 @@ Parameters of type `[switch]` support passing as switches (without a value), and
 - Switch parameters should be treated as boolean values in your scripts. Corrolary: you should not write logic that depends on whether or not the user explicitly passed a value to a switch -- do not attempt to treat a switch as having three states!
 - When you need to pass the value of a switch on to another command, you can either splat it, or specify it using the colon syntax for parameters, as in `-TheirSwitch:$MySwitch`
 
-
 ## Be generous with accept ValueFromPipelineByPropertyName
 
 For the most flexibility, whenever it's practical, you should write your commands to accept their parameters from the pipeline _by property name_. To enhance your ability to match objects, you can add aliases for the parameter name using the `[Alias()]` attribute.
 
-Don't forget that values set from the pipeline are only available in the `process` block.
+Don't forget that values set from the pipeline are only available in the `process` block.