Avoiding backticks in PowerShell Scripting

[chendrayan]

PS Script Analyzer should have a rule to avoid back ticks in Scripting. This kills the flavor of Splatting.

Send-MailMessage -From '[email protected]'
-To '[email protected]' -Subject 'PS Script Analyzer Testing'
-SmtpServer 'XXXXXX' `
-Body 'Testing'

Thanks in advance!

[KirkMunro]

I'm not sure I agree with this one, at least not entirely.

The main issues with backticks is that they are not very visible, and that it is easy to put whitespace after them (which can break things, but which doesn't always break things). But I actually like backticks in some scenarios. For example, I much prefer having a long pipeline with the pipe character lined up than to end lines with a pipe character.

e.g. I prefer this:

Get-Service `
    | ForEach-Object {<# Do some stuff #>} `
    | Stop-Service -WhatIf -PassThru `
    | Format-List -Property *

to this:

Get-Service |
    ForEach-Object {<# Do some stuff #>} |
    Stop-Service -WhatIf -PassThru |
    Format-List -Property *

I've always found the visibility of the pipeline coming down from the first command in the pipeline made it very easy to identify what is being done.

That said, there are plenty of cases where backticks may be used unnecessarily or accidentally or incorrectly that could be warned on, as follows:
a) backticks with trailing whitespace on the same line:

# There is whitespace on the next line after the backtick, you just can't see it.
'Hello' `    

'Goodbye'

b) backticks at the end of a line preceding a line that is empty or only whitespace:

'Hello' `

'Goodbye'

c) backticks where they are simply not required at all:

@{`   
a=1;`
b=2;`
c=3;`
}

[nightroman]

I agree with @KirkMunro . Backtick is a valid PowerShell feature. When it is used for its purpose appropriately there is nothing wrong about it.

This kills the flavor of Splatting.

I consider using splatting just for avoiding bacticks as a questionable practice. Splatting kills TabExpansion on parameters (which works with backticks fine across several lines). It requires an extra variable. It requires an extra hashtable. It may make code to look more complex than it is.

[GoodOlClint]

I guess it really just depends on what the purpose of PSScriptAnalyzer is.
The Community Best Practices say to avoid using Backticks. If it is considered the authority then of course the analyzer needs a rule that does what it says.

If PSScriptAnalyzer is using it's own set of best practices, or if it's getting them from somewhere else that needs to be spelled out somewhere.

Perhaps the rule should exist, but be set to "Warn"

[KirkMunro]

Well, the "Community" Best Practices was created with a relatively small amount of input, given the size of the community. Plus, using backticks or not is about programming style, much like how you indent script blocks, whether or not you start a script block by placing the open enclosure on a new line, etc. I don't think script analysis should be about programming style.

There are other community efforts currently ongoing to flush out a broader set of best practices than what is in the PowerShell.org guide.

[GoodOlClint]

Right, I agree with that. I just think the source of "best practices" should be spelled out. Especially since the 2nd result on a Google search for "Powershell best practices" says you should avoid backticks.

[rkeithhill]

I agree with @KirkMunro. This is mostly a coding style (StyleCop) issue. Although I think the referenced "best practice" has some validity that PSScriptAnalyzer could check for. That is, it could warn when the last non-whitespace char on a line is a backtick but there is trailing whitespace after the backtick. That is usually a problem.

I will also add that "best practices" often cross over between FxCop/Lint type issues and coding style. I think PSScriptAnalyzer should stay away from coding style issues and stick to FxCop/Lint type issues.

[joeyaiello]

First, I really love the discussion here: there's a wide range of opinions and some very valid points, and I'm really glad that you're all so engaged.

However, I want to address the talk around style vs. "best pratices". I think @rkeithhill said it best that there is going to be cross over between what I'll call "potential code/functionality problems" and "style". For instance, while I know the rule itself is very contentious (and let's set aside for a second the discussion around built-in aliases), avoiding aliases in scripts addresses the readability and manageability (i.e. style) of the code when it's shared among many people, but it also avoids the potential for hitting runtime problems on machines where aliases have been altered, overwritten, or are completely non-standard.

While the closest analog to PSSA is FxCop, there's also been a lot of talk around us finally codifying a "style guide" similar to PEP and validating it programatically like pep8. However, Python syntax/style really matters from a functional standpoint, so their lint tools are going to tend to be a lot more verbose about style issues.

On the other hand, I don't think we're really interested in getting pedantic about things like indentation, capitalization, placement of brackets, and all those other age-old style debates that have raged on since the dawn of programming. That's not to say projects shouldn't be internally consistent--we have more specific style guidelines for our own GitHub projects--but I don't think we're in a place where we want to dictate exactly what all PowerShell should look like across the ecosystem. Especially after reading this this excellent write-up Don Jones did on PowerShell.org, I'm really leaning towards the idea that backticks may just be one of these more dogmatic debates where we don't improve anything by picking a side.

Unfortunately, I'm not well-versed enough about backticks to make a call here either way. My initial instinct is to say: they're supported in PowerShell, and they don't really have a purpose in an interactive session, so they probably shouldn't be objectively and completely avoided. However, I'll definitely be asking some of the gurus around the team their thoughts on backticks before we make the call definitively.

As an aside, OP was parsed incorrectly because of the way that backticks are rendered in Markdown. Hopefully this makes a lot more sense (though based on the fact that only -From is highlighted as parameter, it looks like a need to go file an issue at SublimeText/powershell):

Send-MailMessage `
-From '[email protected]' `
-To '[email protected]' `
-Subject 'PS Script Analyzer Testing' `
-SmtpServer 'XXXXXX' `
-Body 'Testing'

[TimCurwick]

Backticks are a style choice. I make liberal use of them when appropriate, as I believe they can add greatly to the readability of a script. When I give my PowerShell best practices lecture, I teach the controversy.

[raghushantha]

This rule falls into the category of Style based rules - At this point we are focusing on functionality based rules, reducing noise from existing rules, making the existing rules more accurate and improvements to the Engine

[KirkMunro]

Raghu, you should create a "Style" tag to tag any items like this so that they may be gathered and addressed later with optional Style rules.