PowerShell Great Debate: Backticks

Here's an age-old debate that we can finally, perhaps, put an end to: The backtick character for line continuation.

The basic concept looks like this:

Get-WmiObject -Class Win32_BIOS `
              -ComputerName whatever `
              -Filter "something='else'"

This trick relies on the fact that the backtick (grave accent) is PowerShell's escape character. In this case, it's escaping the carriage return, turning it from a logical end-of-line marker into a literal carriage return. It makes commands with a lot of parameters easier to read, since you can line up the parameters as I've done.

My personal beefs with this:

  • The character is visually hard to distinguish. On-screen, it's just a couple of pixels; in a book, it looks like stray ink or toner.
  • If you put any whitespace after the backtick, it escapes that character instead of the carriage return, and everything breaks.
  • On some non-US keyboards, it's a difficult character to get to.

In  many cases, you can achieve nice formatting without the back tick.

Do-Something -Parameter this |
  Get-Something -Parameter those -Parm these |
  Something-Else -This that -Foo bar

This is because a carriage return after a pipe, semicolon, or comma is always interpreted as a visual thing, and not as a logical end of line. Of course, some argue that you can make that command prettier by using the back tick:

Do-Something -Param this `
| Something-Else -this that -foo bar `
| Invoke-Those -these those

Here, the pipes line up on the front, making the command into a kind of visual block - but you have to rely on the backticks. You could then argue that a combination of splatting and careful formatting could be nicer, without the backticks:

$do_something     = @{parameter = $this;
                      foo       = $bar}
$invoke_something = @{param     = $these;
                      param     = $those}

Do-Something     @do_something     |
Invoke-Something @invoke_something |

Visually blocked-out, but no back ticks.

And the debate rages on. Your thoughts? Pros? Cons? Why?


[boilerplate greatdebate]

About the Author

Don Jones

Don Jones is a Windows PowerShell MVP, author of several Windows PowerShell books (and other IT books), Co-founder and President/CEO of PowerShell.org, PowerShell columnist for Microsoft TechNet Magazine, PowerShell educator, and designer/author of several Windows PowerShell courses (including Microsoft’s). Power to the shell!


  1. I try to stick to a carriage return after the pipe if the line is getting too long and splatting to shrink down the parameters. When i create the splat i use the following formatting:

    $splat = @{
    Date = $now;
    Then = $future;
    Me = $you

    I find it lines up the parameters nicely without having the first one miles out and also is relatively consistent with other formatting constructs. I know that is a separate debate but if one rule is covering both then that is great consistency which is a big pro. You could pretty much sum it up like this:

    After an open brace, carriage return and tab. The close brace lines up with the opening command (one back tab).

  2. I think splatting is an excellent approach to adding readability (by shortening lines). I like breaking a long line after a pipe and indenting the following line. I don't tend to use backticks for line continuation very often.

    Btw. comments don't seem to be open on the accelerators post. 🙂

  3. I've never liked backticks. Hated using them in vbscript when reading online/in books/etc...
    If I can break up a link with a pipe character, or () or {} I will, but otherwise, I just type out the whole line.
    It makes it easier for "me" to figure out what I was doing X days/weeks/months prior.. becuase sometimes I don't put notes for every line of code 🙂

  4. I have seen and used the back tick, however as above its really hard to spot. And easily missed. Yes it helps, but I find with careful planning it can easily be avoided. Problem is what else could be used in its place? Unless you have the character size correct and you are aware of this "feature" then it's hard to spot. I. Prefer using | or splats
    Recently with a list I have found I can use the comma to break up a line, at least it's easier to spot!

  5. I'll be the odd man out and say that I prefer the backtick. It's a 30-second conversation to teach people that it exists and what it does, and then the scripts I give the customers have a single parameter on each line, which helps my customers copy, paste, and modify those scripts.

  6. I am occasionally faced with lines with commands that have many parameters who's values are too long for a screen image, much less seeing the whole command.. Using back-tics is the most straight forward method to format it so a human can follow it.
    The real problem is the font designers have made back-tic too small, I would like to create a copy of the font and change the bitmap or hints to create a visible character, and use this new font with PowerShell, but that's too much trouble. Splatting helps but is still a mess with long or complex values..

  7. Splatting adds characters, increases file size, etc., etc., and for just formatting a long line of code seems unnecessarily cumbersome. I'll be an odd man out as well by saying the backtick is the perfect character - it isn't really used in any other way so there aren't any rules to remember or confuse, and it's small and inconspicuous. But my closeup eyesight is pretty good so the small character isn't hard for me to detect.

    That being said, if it were a series of piped commands, I would always prefer to use | to help format the command into multiple lines rather than adding the functionally useless backtick.

    • I'll disagree with a couple of bits, just to make conversation ;). First, the backtick is definitely used other ways. It's an escape character, not a line-continuation character, so it's used lots of other ways. It only works for "line continuation" when it immediately precedes the carriage return - which is easy to mess up. When you do mess it up, the resulting error doesn't lead directly to the issue, since the shell essentially mis-parses the line and doesn't know a better error to give you. The little bugger also visually easy to miss in code listings. TOO small and inconspicuous, perhaps! I'll also pish-posh on the "adds characters, increases file size." Nobody's starving for a few bytes of disk space (grin). But man, I envy that closeup eyesight. I remember those days.