Rule request: Avoid enclosing strings with smart quotes
Background (excerpt from Wikipedea Quotation mark definition):
Regarding their appearance, there are two types of quotation marks:
- '…' and "…" are known as neutral, vertical, straight, typewriter, dumb, or ASCII quotation marks. The left and right marks are identical. These are found on typical English typewriters and computer keyboards, although they are sometimes automatically converted to the other type by software.
- ‘…’ and “…” are known as typographic, curly, curved, book, or smart quotation marks...
Summary of the new feature
Quoted strings are sometimes unintendedly replaced when passed by word processors as Microsoft Office applications as MSWord and Outlook. It is recommended to surround strings with unambiguous single quoted or double quoted string as it unnecessary triggers the UseBOMForUnicodeEncodedFile rule with no clear indication of the location.
Proposed technical implementation details (optional)
See (PowerShell based) prototype AvoidSmartQuotedString at: https://github.com/iRon7/PSRules
What is the latest version of PSScriptAnalyzer at the point of writing
1.21.0
Thanks @iRon7 I am going to open this up as a discussion and see if other folks have scenarios that would need this, PowerShell manages smart quotes quite well today
@SydneyhSmith,
Thanks for picking this up as a discussion
PowerShell manages smart quotes quite well today
Agree but just like e.g. the AvoidTrailingWhitespace rule, you better avoid them.
For clarity, maybe add a definition of "smart quotes" to your issue description. Initially I didn't know what you meant. Looking at your test code I guess it's the curly quote styles, like these:
-
‘Test’->'Test' -
“Test”->"Test"
And I agree these shouldn't be used for defining strings. Actually, Powershell itself should fail hard on these quote types and not "handle them".
For clarity, maybe add a definition of "smart quotes"
Thanks for the comment. ...Done.
Powershell itself should fail hard on these quote types and not "handle them" to your issue description
I am not sure whether it should "fail hard" but my recommendation would be to avoid them in anyway (which I think should actually apply for using any non-ASCII character in a PowerShell statement, see also: #1999)