PowerShell Great Debate: Formatting Constructs

Here's an easy, low-stakes debate: How do you like to format your scripting constructs? And, more importantly, why do you like your method?

For example, I tend to do this:

If ($this -eq $that) {
 # do this 
} else {
 # do this
}

I do so out of long habit with C-like syntax, and because when I'm teaching this helps me keep more information on the screen. However, some folks prefer this:

if ($this -eq $that)
{
  # do this 
}
else 
{ 
  # do this
}

Because of my own long habits, I find that hard to read, but it does make it easier to see if your squigglies are lining up properly. It takes up a ton of room, though, and I personally don't follow this as easily as the previous example.

But what's your preference? 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!

8 Comments

  1. Unlikes most C style languages where this is just a matter of Style, in PowerShell, like JavaScript this is actually a matter of parsing, and style affects behavior.

    With classic language keywords it still is a matter of style but { } also indicate scriptblocks in PowerShell.

    Lets pretend that sort doesn't have a decending option, the sort cmdlet can take in a scriptblock to calculate it.. so lets sort decending. we can do

    1..10 | sort {
    -$_
    }

    and the results will be 10 objects out, from 10 downto one.

    however if we change the style.

    1..10 | sort
    {
    -$_
    }

    it still parses and runs but the results are very different in this case there are 11 items output.. and the items are sorted from 1 to 10, not visa versa, and the 11th item is actually the scriptblock itself.

    So you can avoid this trap either by always following the first style, or being very mindful of it when using scriptblocks and passing arguments to functions and cmdlets.

  2. When i was writing my last function i did try
    if (this)
    {
    that
    }

    but i agree that i didn't like the space it was taking up. To me it just didn't look right on screen, so i went through my code and fixed it so that the open brace was on the first line.

  3. I use the more compact "first" style. I don't mind the other method, but it does take more space and leads to more scrolling.

    This is an issue that feels more like a cultural thing, as in some shops format the code one way and some another way. I don't feel very strongly about either one.

  4. I tend to use the first formatting style as well, also most likely from my (now eons old) C/Perl coding days. The second method offends my eye and to me at least just looks wrong.

    We all have our coding idiosyncrasies I guess ...

  5. I prefer the braces on a separate line because it creates white space and when you have lots of nested loops and condition statements it makes the code a bit easier to scan and find the block you're interested in. It's also easier to see which braces match up with each other. Overall, I think it makes the code easier to maintain.

  6. With the new pipeline paradigm in Powershell I had to come up with a new style component. I choose to indent the second line of a pipeline, and keep all others at the same level. The idea is the original source of the pipe stands out, and all other dependents processes are at the same level. There is no need to indent for each pipeline process. For example:

    Get-Process | # pipeline root
    Where-Object { ... } |
    Sort-Object ... |
    ForEach-Object {
    ...
    } |
    ForEach-Object {
    $_ | # 2nd pipeline root
    Where-Object { ... } |
    Sort-Object ... |
    Write-Output ...
    }

  7. With the new pipeline paradigm in Powershell I had to come up with a new style component. I choose to indent the second line of a pipeline, and keep all others at the same level. The idea is the original source of the pipe stands out, and all other dependents processes are at the same level. There is no need to indent for each pipeline process. For example:

    Get-Process | # pipeline root
    [tab]Where-Object { ... } |
    [tab]Sort-Object ... |
    [tab]ForEach-Object {
    [tab][tab]...
    [tab]} |
    [tab]ForEach-Object {
    [tab][tab]$_ | # 2nd pipeline root
    [tab][tab][tab]Where-Object { ... } |
    [tab][tab][tab]Sort-Object ... |
    [tab][tab][tab]Write-Output ...
    [tab]}

  8. ... in PowerShell, like JavaScript this is actually a matter of parsing, and style affects behavior.

    If your intention is to have sort return descending numbers, then there is only one correct answer. Style never affects behavior.
    If the "style" is affecting the behavior, then it's not really a "style" issue is it?

    As for which one to use, I prefer Allman for my personal scripts, but the one we use at work is 1TBS.

    However, there is one important point here. If you are using 1TBS (Example 1 above), please be aware that PowerShell_ISE won't let you collapse the else block when the if block is already collapsed. Instead I would recommend the Stroustrup variant
    https://en.wikipedia.org/wiki/Indent_style#Variant:_Stroustrup

    If ($this -eq $that) {
    # do this
    }
    else {
    # do this
    }