Indentation and Formatting Style for PowerShell Code

My preferred indentation style when writing PowerShell code is Stroustrup style because I don’t like my code to cuddle (there’s no cuddled else in Stroustrup style). I occasionally hear from others that they don’t like this style because it doesn’t work from the PowerShell console.

While it doesn’t work by default, there’s a trick to making that style work from the PowerShell console. Simply press Shift+Enter instead of just Enter at the end of the line before the else.

I also prefer to write my code with the curly brace on the same line.

Why? Because I like consistency. Writing code with the curly brace on the next line, like in the following example, doesn’t work every time. You end up having to modify how things are done on a case by case basis. For example, you can’t place the curly brace for Where-Object on the next line. I even tried the Shift+Enter trick with no luck.

According to a discussion on the Unofficial PowerShell Best Practices and Style Guide, using both of these styles is technically a combination of Stroustrup style and the One True Brace Style variant (OTBS) variant of K&R. There was also another interesting discussion about “Where to put braces” in the same style guide a while back.

What’s your preferred code writing style for PowerShell and why? Whatever style you choose, stick with it and be consistent. Formatting your code is a form of art in itself. If you’re contributing to someone else’s code such as an open-source project on GitHub, be sure to follow their formatting style as refactoring all of their code to your style won’t be well received to say the least.


Update 9/6/18

Joel Bennett mention on Twitter that “Shift + Enter” requires PSReadline. I did some testing and indeed it does, but what I also found out is that Else can be on a separate line and it works by default without having to use “Shift + Enter” as long as the PSReadline module isn’t loaded.

µ

4 Comments

  1. Sean Wheeler

    Placing the opening brace on the same line looks nicer in editors that support code folding, VS Code and PowerShell ISE. It also scans better. The trailing open brace is a cue that there is more code to follow and that the current line is not a standalone statement.

    Final closing braces should always be on their own line

    This is a clear signal to the reader that they have come to the end of a block of code. This is especially helpful for long or deeply indented code blocks.

    I prefer to put the secondary keywords (else, catch, etc.) on the same line with the previous closing brace (aka cuddled). There are cases where this may not best format for readability. In those cases, I put the catch on a new line. For example:

    “`powershell
    try {
    Do-SomethingDangerous
    }
    catch [SomeException] {
    Explain-WhatHappened
    }
    catch [SomeOtherException] {
    Explain-WhatHappened
    }
    finally {
    Cleanup-MyMess
    }
    “`

    Be careful not to add blank lines after the closing brace. PowerShell sees the blank line as a statement terminator. This will truncate your code block and could cause errors and unexpected results. The following example will not run properly.

    “`powershell
    # Don’t do this!!!
    try {
    Do-SomethingDangerous
    }

    # catch/finally will fail
    catch [SomeException] {
    Explain-WhatHappened
    }

    finally {
    Cleanup-MyMess
    }
    “`

    Reply
  2. jamesone111

    A lot of layout styles grew out of formatting for fanfold paper what was in portrait format , and it continues to be passed on . It may also be influenced by using lines of code as a metric and a blank line or an open-brace-only line still counts. Or by people starting in pascal which uses “begin” and “end” which naturally go on their own lines and moving onto C and its descendant which replaces these with { and }

    If we work on landscape monitors, putting braces on their own lines means we have to scroll more, and limits how much of the code fits on the screen at once.
    So my rules are
    Open brace is always on the line of the command which it belongs to.
    If the contents of the brace is a single short line it goes on the same line as the open (and close) brace
    Otherwise the contents are indented and the closing brace is on its own line. .

    The most space efficient way is to put the closing brace at the end of the last indented line. However this makes it harder to see if all the braces which have been opened have also been closed. I’ve found I align all the punctuation in similar lines because it is easier to spot differences, whether they are errors (that line is missing a bracket) or just differences (do this to that with these options, now do it to something else, with the same options).

    The consistency thing. You can’t put the brace for a script block parameter for a cmdlet / function on a new line (unless you escape the return) because new line means “end of this pipeline of commands”. But when you have a control statement the parser knows that a for, or while or if statement isn’t done until it meets the script block.
    Of course you can write
    $stuff | foreach-object `
    {
    Fettle $_
    }
    and escape the return character. but things get ugly if you have begin, process and end script blocks.

    Reply
  3. Gyz

    Like you , I prefer the great Stroustrup style even with some extra line spacing for readability. I also
    experienced PSReadline sometimes can be a blessing and a curse at the same time

    Reply

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: