Rule request: Prefix parameters with an unambiguous (ASCII) hyphen-minus

[iRon7]

Hyphen-minus characters are sometimes unintendedly replaced when passed by word processors as Microsoft Office applications as MSWord and Outlook. It is recommended to prefix parameters with an unambiguous hyphen-minus as Unicode dashes might cause parsing errors in earlier versions of PowerShell.
Besides it unnecessary triggers the UseBOMForUnicodeEncodedFile rule with no clear indication of the location.

PowerShell 7

# .\Test.ps1
Write-Host “test” –ForegroundColor ‘Red’ -BackgroundColor ‘Green’

Invoke-ScriptAnalyzer .\Test.ps1

RuleName                            Severity     ScriptName Line  Message
--------                            --------     ---------- ----  -------
PSAvoidUsingWriteHost               Warning      Test.ps1   1     File 'Test.ps1' uses Write-Host. Avoid using
                                                                  Write-Host because it might not work in all hosts,
                                                                  does not work when there is no host, and (prior to
                                                                  PS 5.0) cannot be suppressed, captured, or
                                                                  redirected. Instead, use Write-Output,
                                                                  Write-Verbose, or Write-Information.
PSUseBOMForUnicodeEncodedFile       Warning      Test.ps1         Missing BOM encoding for non-ASCII encoded file
                                                                  'Test.ps1'

Windows PowerShell (5.1)

Windows PowerShell (5.1) still has issue with EM-dashes:

.\test.ps1
At C:\Users\Gebruiker\downloads\Test.ps1:1 char:25
+ ...  “test� –ForegroundColor ‘Red’ -BackgroundColor ‘Green’
+                   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The string is missing the terminator: ".
    + CategoryInfo          : ParserError: (:) [], ParseException
    + FullyQualifiedErrorId : TerminatorExpectedAtEndOfString

Invoke-ScriptAnalyzer .\Test.ps1

RuleName                            Severity     ScriptName Line  Message
--------                            --------     ---------- ----  -------
TerminatorExpectedAtEndOfString     ParseError   Test.ps1   1     The string is missing the terminator: ".
PSAvoidUsingWriteHost               Warning      Test.ps1   1     File 'Test.ps1' uses Write-Host. Avoid using
                                                                  Write-Host because it might not work in all hosts,
                                                                  does not work when there is no host, and (prior to
                                                                  PS 5.0) cannot be suppressed, captured, or
                                                                  redirected. Instead, use Write-Output,
                                                                  Write-Verbose, or Write-Information.
PSUseBOMForUnicodeEncodedFile       Warning      Test.ps1         Missing BOM encoding for non-ASCII encoded file
                                                                  'Test.ps1'

Proposed technical implementation details (optional)

See (PowerShell based) prototype UseHyphenMinusForParameter at: https://github.com/iRon7/PSRules

What is the latest version of PSScriptAnalyzer at the point of writing

1.21.0

[SydneyhSmith]

Thanks for all the requests @iRon7 , just a reminder that you can create and publish custom rules on the Gallery-- if you want to get these out there-- its unlikely that we would be able to incorporate them into the product, especially in a timely matter

[iRon7]

@SydneyhSmith,

just a reminder that you can create and publish custom rules on the Gallery

Yes, I am currently building a set of additional rules for our environment and also considering to publish them at the gallery.
The point is that I am looking into a way to get them automatically installed as a part of the Managed Extensibility Framework (MEF), see also: #1551 (comment)